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SOME  GUIDELINES  FOR  EFFECTIVE  TASK  DESIGN  IN  COMMAND  AND  CONTROL 
SIMULATIONS 


BRIEF 


This  volume  reports  on  the  follow-on.  Phase  2,  research  effort  on  the 
design  of  an  Integrated  Division-Level  Battle  Simulation  for  Research, 
Development,  and  Training.  It  develops  the  logical  framework  for 
simulated  staff  processing  as  a  basis  for  developing  guidelines  for 
the  design  and  implementation  of  player  tasks  in  an  interactive  simu¬ 
lation.  It  examines  the  independent  and  interactive  effects  of  the 
staff  system  being  emulated  (manual  or  ADP-assisted),  staff  module 
configuration,  conmunication  media  within  the  staff  module,  and  experi¬ 
mental  purpose  of  task  assignment.  On  the  assumption  that  a  specific 
staff  system  is  being  emulated  and  that  a  complete  SOP  for  that  system 
is  available,  procedures  are  then  developed  for  adding  to  or  modifying 
those  procedures  as  required  to  insure  that  the  required  variables  are 
controlled  or  are  measurable.  The  material  covered  in  this  and  a 
companion  volume,  "On  the  Design  of  Simulations  of  Command  and  Control 
Processes,"  is  essentially  identical  except  for  Section  5. 

Requirement: 

Prepare  a  report  discussing  principles  of  task  design  for 
interactive  simulations,  including  trade-offs  among  task  realism, 
credibility,  and  impact  on  performance  measurement,  and  providing 
guidelines  for  effective  task  design.  In  the  light  of  the  design 
problem  in  Phase  1  which  gave  rise  to  this  task,  it  may  be  thought 
of  as  finding  answers  to  the  following  questions: 

•  What  are  the  principles  of  task  design  for  Interactive 
simulations? 

•  What  are  the  trade-offs  among  task  realism,  credibility, 
and  impact  on  performance  measurement? 

•  Do  they  provide  guidelines  for  effective  task  design? 

This  research  effort  was  carried  out  in  parallel  with  a  second  effort 
whose  purpose  was  to  develop  a  logical  framework  for  simulated  staff 
processing  that  can  accommodate  variant  human  performance  from  the 
team  players  in  populated  staff  .nodules  as  we’l  as  simulated  variant 
performance  in  simulated  modules.  It  was  also  to  determine  whether 
alternative  interface  locations  (between  live  players  end  the  simu¬ 
lation)  are  feasible.  The  successful  accompl ishment  of  both  tasks 
required  search  of  largely  common  data  sources  and  both  required 
development  of  the  detailed  logical  information  flow  structure  within 
the  staff  modules  that  comprise  the  decision  making  node  in  military 
command  control  systems.  Therefore,  the  technical  approach  to  both 


consisted  of  five  steps  of  which  the  first  four  were  common  to  both 
efforts.  The  five  steps  for  the  effort  which  is  the  subject  of  this 
report  were: 

1.  A  literature  search  covering  human  behavior  in 
command  control  decision  nodes  and  of  extant 
games  and  simulations  was  conducted. 

2.  A  detailed  formulation  of  the  staff  processing 
required  to  process  all  message  traffic  postulated 
in  the  Phase  1  design  was  developed.  This  analysis 
began  by  defining  the  elementary  operations  per¬ 
formed  by  a  single  man— the  basic  building  blocks 
of  staff  procedures.  The  sequence  in  which  these 
elementary  operations  need  be  performed  to  process 
the  message  types  selected  in  Phase  1  was  estab¬ 
lished  in  the  form  of  event  thread  charts. 

3.  The  points  of  occurrence  of  variant  human  performance, 
i.e.,  of  the  error  classes  identified  in  Step  1  were 
identified.  The  frequency  of  occurrence  was  esti¬ 
mated  since  no  hard  data  on  error  frequency  were 
available. 

4.  A  logical  framework  was  then  established  for  the 
design  of  simulated  staff  modules  to  permit  such 
simulated  modules  to  accommodate  variations  in 
human  behavior  in  populated  modules  and  reflect  thn 
effects  of  human  errors  in  battle  outcomes.  Simi¬ 
larly,  the  framework  was  established  to  insert 
variant  performance  (errors)  into  the  processing 
performed  in  simulated  modules  so  that  the  reaction 
to  sucn  performance  by  populated  modules  could  be 
observed  and  measured. 

5.  The  purpose  of  the  staff  system  and  the  nature  of 
staff  decision  making  were  examined.  The  inter¬ 
actions  between  the  staff  system  being  emulated, 
simulation  design  and  configuration,  the  internal 
communication  within  the  staff  module,  and  the 
purpose  of  the  experiment  are  developed  and  their 
impact  on  experimental  design  and  performance  mea¬ 
surement  is  defined.  The  contents  and  level  of 
detail  of  the  Standing  Operating  Procedure  (SOP) 
required  to  emulate  a  specified  staff  system  are 
listed.  Based  on  the  assumption  that  such  an  SOP 
is  available  or  has  been  developed,  a  set  of  pro¬ 
cedures  is  then  developed  for  formulating  task 
design  based  on  the  configuration  and  c'ass  of 
experiment. 
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SECTION  1 


INTRODUCTION 


1.0  PURPOSE  AND  SCOPE 

The  results  of  the  follow-on,  Phase  2  effort  on  the  design  of 
an  Integrated  Division-Level  Battle  Simulation  for  Research,  Develop¬ 
ment,  and  Training  are  contained  In  two  companion  volumes: 


•  On  the  Design  of  Simulations  of  Command  and  Control 
Processes 

•  Soto  Guidelines  for  Effective  Task  Design  In  Command 
and  Control  Simulations 

Although  based  on  the  logic  of  the  original  Phase  1  top-down  design^, 
they  transcend  the  original  work  In  that  they  develop  basic  considera¬ 
tions  that  apply  to  the  design  of  any  simulation  of  command  and  control 
and  to  the  design  of  player  tasks  In  such  simulations  when  used  as 
experimental  tools. 


The  Phase  2  effort  has  centered  on  two  additional  design 
requirements  that  were  acknowledged,  but  not  fully  addressed,  during 
the  Phase  1  design  work.  These  requirements  can  be  stated  as  follows: 


TASKS  (KEY  WORDS) 

1.  Prepare  a  report: 

•  Detailing  the  critical 
dimensions  and  parame¬ 
ters  of  human  performance 
In  command  and  control 

e  Providing  a  design  for 
simulations  of  command 
and  control  processes 


2.  Prepare  a  report: 

•  Discussing  principles 
of  task  design  for 
Interactive  simulations 


BASIS 


•  Search  of  behavioral 
science  and  gaming 
literature 


•  Analysis  of  existing 
Interactive  simulations 
(to  Include  design 
developed  in  Phase  1) 


#  Search  of  behavioral 
science  and  gaming 
literature 


Tiede,  R.  V.,  Burt,  R.  A.  and  Bean,  T.  T.,  Design  of  an  Integrated 

Division-level  Battle  Simulation  for  Research,  ^velooment.  ar 
rv _ •  i  ■!  1 1  i  m  r~  .  — 


Including  trade-offs 
among  task  realism, 
credibility,  and  Impact 
upon  performance  mea¬ 
surement 

•  Prov.ding  guidelines  for 
effective  task  design 

In  the  light  of  the  design  problems  In  Phase  1  which  gave  rise  to 
these  tasks,  they  may  be  thought  of  as  finding  answers  to  the  following 
questions: 

•  Variant  (Non-Standard)  Human  Staff  Performance 

—Can  the  simulated  staff  modules  be  designed  so 
that  they  will  accommodate  variant  human  per¬ 
formance  on  the  part  of  one  or  more  populated 
staff  modules?  This  will  allow  behavioral 
scientists  investigators  to  examine  the  effect 
of  human  stcff  errors  on  battle  outcome. 

—Can  the  simulated  staff  modules  themselves  be 
made  to  generate  common  staff  errors?  This 
will  allow  examination  for  corrective  responses 
that  might  be  instituted  by  the  populated 
modules. 

•  Controllable  Interface  Boundaries 

—  Is  it  feasible,  in  the  interest  of  economy  of 
operations  and  player  motivation,  to  vary  the 
Interface  boundaries  of  the  staff  nodules? 

This  will  allow  the  controller/investigator, 
in  some  experiments,  to  eliminate  certain 
repetitive,  low-skill  procedural  tasks  (e.g., 
answering  radios  or  telephones,  transmitting 
messages,  routine  filing,  etc.)  from  the  live 
staff  procedures. 

•  Task  Design  for  Interactive  Simulations 

—What  are  the  principles  of  task  design  for 
interactive  simulations?  What  art  the  trade¬ 
offs  among  task  realism,  credibility,  and 
Impact  on  performance  measurement,  and  do 
they  provide  guidelines  for  effective  task 
design? 

These  problems  require  the  detailing  of  the  relevant  dimensions  end 
parameters  of  human  performance  in  command  and  control  as  well  as  a 


§  Analysis  of  existing 
Interactive  simulations 
(to  include  design 
developed  in  Phase  1) 


1-2 


< 


more  detailed  design  of  the  staff  procedures  to  be  established  for  the 
players  in  populated  modules  or,  correspondingly,  to  be  represented 
in  simulated  modules. 

The  report  identifies  three  classifications  of  human  errors 
that  can  occur  during  the  processing  of  staff  actions  and  therefore 
lead  to  the  Blue  force  failing  to  accomplish  its  assigned  mission. 

The  human  error  types  are  based  on  a  search  of  behavioral  science  and 
war  gaming  literature  and  an  analysis  of  the  event  sequence  relation¬ 
ships  in  the  Phase  1  design.  The  latter  analysis  included  the  defi¬ 
nitions  of  27  "elementary  operations"  (for  live  staff  players)  or 
Class  1  events  (for  simulated  modules).  All  staff  procedures  are 
composed  from  these  basic  procedural  steps. 

In  this  framework,  the  report  addresses  the  basic  design 
problems  described  above.  With  respect  to  the  first  problem,  it  shows 
that  simulated  staff  processing  can  be  designed  in  such  a  manner  that 
simulated  modules  "accept  and  pass  on"  faulty  or  substandard  staff 
actions  generated  by  one  or  more  populated  staff  sections,  thereby 
allowing  the  substandard  performance  to  be  reflected  in  the  battle 
outcome.  The  simulated  modules  can  also  be  made  to  exhibit  staff 
errors  themselves,  based  on  stochastic  or  fixed  switches  preset  by 
the  exper',  <>enter(s) . 

The  second  and  third  problems,  that  of  controllable  interface 
boundaries,  and  the  discussion  on  the  principles  of  task  design  under 
the  enhanced  basic  design  concept,  are  added  as  Section  5  of  the  two 
respective  reports  on  this  effort. 

1.1  RELATIONSHIP  TO  THE  PHASE  1  DESIGN 

The  Phase  1  design  consisted  of  two  parts:  (1)  the  basic 
design  concept  for  the  Integrated  Division-Level  Battle  Simulation 
and  (2)  a  proposed  initial  implementation  of  the  concept.  The  basic 
design  concept  was  for  a  general  interactive  simulation  model  with 
sufficient  scope  and  flexibility  that  it  could  be  applied  alterna¬ 
tively  to  behavioral  research,  to  ti-2  development  and  evaluation  of 
new  tactics,  or  to  the  training  of  staff  personnel .  The  system  con¬ 
tained  six  "plug-in"  modules,  each  of  which  could  either  be  "played" 
by  human  players  or  else  be  simulated  by  means  of  rules  Imposed  oy 
the  computer  and/or  controllers.  Five  of  these  modules  represented 
the  Blue  Command  Group  and  its  four  principal  staff  sections;  the 
sixth  module  was  the  Red  Cownand.  The  system  provided  for  the  play 
of  a  division-level  (alternatively  corps-level)  war  game  in  ^hich  the 
"configuration  of  play"  could  be  selected  beforehand.  The  configuration 
of  piay  <s  the  particular  combination  of  populated  modules  and  simu¬ 
lated  modules  chosen  among  the  six.  The  play  Itself  Involved  not 
only  the  simulated  combat  between  the  opposing  forces  but  also  the 
varying  states  of  knowledge  the  opposing  commanders  use  as  the  basis 
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for  their  tactical  decisions.  The  system  handled  the  information  flow 
of  approximately  seventy-five  standard  tactical  messages,  and  was 
based  on  an  event-oriented  simulation  using  approximately  350  separately 
defined  events.  These  events  covered  staff  actions,  staff  coordination, 
staff  output,  and  staff  input  as  well  as  the  simulated  battle  occur¬ 
rences  . 


•The  second  part,  the  proposed  implementation  of  the  concept, 
developed  a  physical  layout,  the  system  architecture,  the  software 
requirements,  and  precise  specification  of  the  controller  functions 
for  the  initial  implementation.  These  key  elements  imposed  three 
specific  constraints  on  the  scope  of  the  full  concept: 

•  One  or  two  human  controllers,  aided  by  computerized 
preprocessing  capabilities  and  an  interactive 
executive  control  routine,  would  control  the  play 
of  the  game. 

•  Configurations  of  play  would  be  limited  to  no  more 
than  two  populated  staff  modules  (any  two  out  of 
six  modules) . 

t  Blue  staff  modules  would  operate  under  a  manual 
staff  system  only. 

This  report  now  addresses  the  two  additional  design  require¬ 
ments  in  a  manner  that  is  consistent  in  all  respects  with  the  struc¬ 
tural  concept  of  Part  1.  The  enhanced  basic  design  concept  presented 
here,  on  the  other  hand,  requires  that  the  proposed  initial  imple¬ 
mentation  in  Part  2  be  modified. 

1.2  TECHNICAL  APPROACH 

The  technical  approach  used  in  the  Phase  2  design  work  was 
based  on  a  common  point  of  departure  for  the  two  separate  design  re¬ 
quirements.  The  common  basis  consisted  of  a  literature  search  for 
relevant  background  information  and  an  analysis  of  existing  interactive 
simulations,  including  the  Phase  1  design  itself.  The  approach  con¬ 
sisted  of  the  following  six  steps  in  which  the  first  four  were  the 
common  prerequisites  to  the  last  two: 

•  Step  1  -  Literature  search  covering  human  behavior 

in  command  and  control  and  interactive 
war  game  simulations. 

•  Step  2  -  Detailed  formulation  of  the  staff  processing 

required  in  the  framework  of  the  tactical 
message  specified  in  the  Phase  1  design. 
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t  Step  3  -  Identification  of  the  points  of  occurrence 
and  frequency  of  occurrence  of  variant 
human  performance  in  the  staff  processing. 

•  Step  4  -  Development  of  the  logical  framework  for 

simulated  staff  processing  so  that  the 
model  design  can  accommodate  variant 
human  performance  from  the  team  players 
in  populated  modules  as  well  as  simulated 
variant  performance  in  simulated  modules. 

•  Step  5  -  Examination  of  the  staff  processing  struc¬ 

ture  to  determine  whether  alternative 
interface  locations  are  feasible,  con¬ 
sidering  task  realism,  performance  measure¬ 
ment  requirements,  and  model  implementation. 

•  Step  6  -  Consideration  of  the  special  requirements 

for  task  design  imposed  by  the  use  of  such 
simulations  as  experimental  tools. 

1.3  ORGANIZATION  OF  THE  REPORT 

Section  2  presents  the  results  of  the  review  of  the  behavioral 
science  and  war  gaming  literature.  The  review  was  conducted  in  order 
to  identify:  the  critical  dimensions  of  human  performance  in  command 
and  control,  the  parameters  describing  the  variance  in  such  human 
performance,  and  the  way  existing  simulations  reflect  the  variance. 
Based  upon  the  review,  the  essential  operations  that  must  be  performed 
in  information  processing  and  decision-making  were  identified,  although 
measurements  of  variance  were  sparse.  Error  analyses  were  found  to 
be  highly  situation-oriented  and  consequently  did  not  lend  themselves 
to  this  effort.  As  a  result  three  classes  of  errors  were  defined 
solely  for  the  purposes  of  relating  variant  staff  performance  to 
battle  outcome  in  the  model. 

Section  3  then  defines  the  elementary  staff  operations  that 
must  be  performed  in  command  and  control  systems.  These  operations 
are  based  in  part  on  the  material  identified  in  Section  2.  The  re¬ 
quired  staff  processes,  categorized  solely  from  the  tactical  infor¬ 
mation  messages  set  forth  in  the  Phase  1  design,  are  then  developed 
using  even*  thread  charts  to  link  the  elementary  staff  operations  in 
appropriate  event  sequences.  The  section  is  concluded  with  a  matrix 
showing  the  procedural  step  points  at  which  the  three  classes  of 
human  error  can  occur. 

Section  4  addresses  the  first  design  requirement  by  providing 
a  logical  design  framework  for  accommodating  variant  human  performance 
in  the  overall  model  design.  The  discussion  begins  by  tracing  the 
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tactical  information  flow  in  the  model  as  a  whole,  then  refines  this 
flow  by  incorporating  details  of  the  staff  procedures  developed  in 
Section  3  and  by  showing  where  human  errors  are  involved  in  the  flow 
cycle.  The  logical  design  for  simulated  staff  processing  is  then 
developed  from  this  framework.  The  implied  system  overhead  associated 
with  the  enhanced  design  is  also  discussed. 

•  Section  5  of  the  volume  entitled  On  the  Design  or  Simulations 
of  Command  and  Control  Processes  discusses  the  feasibility  of  varying 
the  interface  boundaries  of  the  staff  modules  to  include  trade-offs 
among  task  realism,  credibility,  and  impact  upon  performance  measure¬ 
ment. 

Section  5  of  the  volume  entitled  Some  Guidelines  for  Effective 
Task  Design  in  Command  and  Control  Simulations  concludes  with  the 
principles  of  task  design  based  on  the  overall  model  design  with  the 
new  extensions. 


SECTION  2 


HUMAN  PERFORMANCE  IN  COMMAND  AND  CONTROL 


2.0  INTRODUCTION 

This  section  reports  on: 

•  The  review  of  the  behavioral  science 

literature  to  determine: 

The  critical  dimensions  of  human 
performance  In  command  and  control,  l.e., 
the  kinds  of  errors,  omissions,  delays, 
and  Invalidities  Introduced  by  human 
Information  processing  and  decision 
making. 

The  parameters  describing  the  frequency, 
range,  and  distribution  of  such  human 
performance  as  a  function  of  environment, 
stress,  form  of  data  presentation,  etc. 

•  The  analysis  of  existing  Interactive  and 

non- interactive  simulations  to  determine  how 
they: 

Reflect  variations  In  human  performance 
In  simulation  outcomes. 

Design  tasks  and  procedures  for 
Information  processing  on  a  selective 
basis. 

To  assist  In  this  determination,  SAI  reviewed  an  extensive 
quantity  of  behavioral  science  and  gaming  literature  to  ascertain  the 
critical  dimensions  and  parameters  of  human  performance  In  command  and 
control.  The  sought-after  dimensions  would  describe  the  kinds  of 
behavior  (errors,  omissions,  delays,  and  Invalidities)  Introduced  by 
human  Information  processing  and  decision  making;  these  parameters 
would  provide  an  Initial  basis  for  modeling  the  frequency,  range,  and 
distribution  of  these  dimensions  as  a  function  of  environment,  stress, 
training,  form  of  data  presentation,  etc.  It  was  hoped  that  the 
review  of  existing  interactive  and  non-lnteractlve  war  gaming 
simulations  would  provide  Insight  as  to  how  previous  models  have 
reflected  variance  In  human  performance  In  simulation  outcomes,  and 
how  tasks  and  procedures  for  Information  processing  were  designed  on  a 
selective  basis. 
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2  A 


REVIEW  OF  EXISTING  WAR  GAMING  SIMULATIONS 


Two  primary  sources  were  reviewed  to  obtain  a  listing 
of  all  war  gaming  simulation  models  which  might,  even  remotely, 
address  C^I  functions.  Table  2-1  contains  a  listing  of  each  of  these 
models,  a  summary  description  of  each  model's  purpose  and  the  model's 
proponent.  Although  each  of  the  models  have  Interesting  aspects  that 
would  be  of  Interest  In  the  design  of  the  battle  outcome  generator, 
only  three  -  ADVICE  II,  FOURCE,  and  HETMAN  -  provide  any  real 
advancement  In  the  modeling  of  human  performance  In  combat  simulation 
outcomes. 


2.1.1  ADVICE-II5 


The  ADVICE-II  model  Is  a  force- on- force,  computer-assisted, 
division-level  war  game.  The  computer  Is  used  only  to  perform  the 
time-consuming  clerical,  filing,  computational  and  data  retrieval 
tasks.  Specifically,  the  computer  keeps  all  records,  maintains  the 
data  base,  performs  the  numerical  assessment,  and  generates  all 
standard  format  reports  to  players. 

The  reports  are  delayed  and  the  numerical  content  of  the 
reports  Is  degraded  by  means  of  stochastic  routines  with  variable 
parameters  that  can  reflect  different  Information  processing 
performance  levels.  In  addition.  Information  about  enemy  activity  Is 
stochastically  degraded  to  reflect  the  performance  of  the  Intelligence 
system  extension  to  the  command  and  control  elements. 


3  Catalog  ofUar  (Sawing  and  Military  Simulation  Models, 
Studies,  Analysis,  and  Gaming  Agency, 

Joint  Chiefs  of  Staff,  8th  Edition,  January  1980 

4  Tabulation  of  Models  of  Interest  to  CAA,  Methodol ogy , 
Resources  and  Computation  Directorate,  U.S.  Army  Concepts 
Analysis  Agency,  July  1979 


Tlede,  R.  V.,  Leake,  L.  A.,  and  Whipple,  $•  Jr., 

Information  Flow  and  Combat  Effectiveness. 

(Research  Analysis  Corporation,  Report  MAc-R- 100,  April  1970) 
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TABLE  2-1 


CURRENT  SIMULATION  MODELS  PERTINENT  TO  C3I 


MOOEL  (PROPONENT) 
Advice  II  (CACDA) 

CAMMS  (CATRAOA) 

CARMONETE/ATHELO  (CAA) 

'  CEM  IV  (CAA) 

C0W4EL  II. 5  (CAA) 

CRM  (OCA) 


PURPOSE 


A  computer-assisted  division-level 
force-on- force  war  game  which  models 
the  flow  of  tactical  Information  In 
ground  combat  with  realistic 
feedback  to  staff. 

A  computer-assisted  brigade-level 
training  simulation  used  to  train 
battalion  and  brigade  command  groups 
In  the  exercise  of  command  and 
control . 

A  computerized,  battalion  level 
Monte  Carlo,  time- sequenced  critical 
event  simulation  of  a  combined  arms 
air/ground  war  game. 

A  two-sided,  fully  automated, 
deterministic  model  capable  of 
aggregating  conventional  warfare 
results  as  a  series  of  four  day 
theater  level  cycles. 

A  computerized,  analytical,  general 
war  battle  model  designed  to  process 
Input  data  to  develop  a  battle 
between  division-sized  forces. 

A  computer-assisted,  general  war, 
analytical  model  which  examines 
residual  cumiunl cations  assets  and 
the  ability  to  restore  Interrupted 
users. 


2-3 


TABLE  2-1  (CONT'O) 

CURRENT  SIMULATION  MOOELS  PERTINENT  TO  C3I 


MODEL  (PROPONENT) 
CREST  (CNO) 

DADENS-C2  (ADS/DCD) 


OIVSIFT  (SAI) 


DIVWAG  (CACDA) 


FIRST  BATTLE  (CAC) 

FOURCE  (TRANSANA) 


PURPOSE 


A  computerized,  analytical  model 
that  evaluates  the  effectiveness  of 
one  unit  successfully  evading  one  or 
more  adversaries. 

A  computerized,  analytical,  general 
war  and  damage  assessment/weapons 
effectiveness  model  designed  to 
simulate  either  one-  or  two-sided 
war  games. 

A  computer  model  that  measures  the 
action  handling  effectiveness  of  a 
conmand  post  staff  when  the  staff  Is 
loaded  by  the  events  of  a  combat 
scenario. 

A  player-assisted,  analytical, 
general  division  war  model  which 
performs  the  firepower,  mobility, 
target  acquisition,  and  combat 
service  support  functions. 

A  low  resolution  battlefield 
simulation  system  designed  to 
exercise  division  and  corps  staffs. 

A  division-level  non-1  interactive 
force-on- force  combat  mcdel  with 
emphasis  on  the  simulation  of  staff 
performance  and  combat 
Informatlon/lntelllgence  flow. 
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TABLE  2-1  (CONT'O) 


CURRENT 


MODEL  (PROPONENT) 
TDAHEX  (OSD) 

MANMODE L  (ARI ) 


MATSS  (SA1) 


HETMAN  (ARI) 


NNWS  (CNO) 


SIMULATION  MODELS  PERTINENT  TO  C3I 


PURPOSE 


A  computer-assisted,  limited  war, 
analytical  and  training  model 
representing  maneuver  and  its 
consequences. 

A  computer  simulation  of  the  data 
entry  processes  that  focuses  on 
system  tasks  and  procedures  In  an 
effort  to  estimate  performance  as  it 
pertains  to  data  entry.  By  varying 
input  parameters,  MANMODEL  permits 
system  designers  to  explore  the 
effects  on  the  data  entry  process  of 
changes  In  manning  levels,  training, 
personnel  selection  and  other 
factors.  It  provides  an  evaluate  e 
vehicle  for  comparison  of 
alternative  system  configurations, 
operational  procedures  and  personnel 
characteristics  ( e . g . ,  training, 
aptitude,  motivation). 


A  dynamic  computer  simulation  of 
target  acquisition,  attack  decision, 
and  attack  processes  against  deeper 
targets  that  incorporates  multi¬ 
sensor  fusion  and  time  delays. 

A  computer  model  for  simulating  the 
information  processing  actions  of 
army  staff  during  field  exercises 
using  a  computer-based  message 
handling  system. 

A  computer-assisted,  analytical, 
limited  war  model  of  the  interaction 
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TABLE  2-1  (CONT'D) 


CURRENT  SIMULATION  MODELS  PERTINENT  TO  C3I 


MODEL  (PROPONENT) 


PURPOSE 


NEWAIR  (SHAPE) 


QUICK  (SAGA) 


SIM  II  (CNO) 

SIMTOS  (ARI ) 


STAB  II  (NASC) 


and  results  of  US/NATO  Naval  forces 
versus  Soviet  forces  on  a  theater¬ 
wide  basis, 

A  computer-assisted  theater-level 
air  battle  simulation  model  which 
addresses  the  outcome  of  a  conflict 
between  air  forces  employing 
conventional  weapons. 

A  general  war  gaming  system  designed 
to  assist  the  military  war  gaming 
analyst  at  the  JCS  level  with  the 
generation  of  detailed  strategic 
nuclear  war  plans. 

A  computerized,  analytical,  limited 
war  model  of  detailed  and  rigid 
naval  warfare  situations. 

A  computer-assisted  simulation  which 
permits  laboratory  research  on 
tactical  military  decision  making 
behavior,  particularly  with  respect 
to  Information  flow  and  display 
variables. 

A  computerized,  analytical  general 
war  model  used  to  analyze  the 
effectiveness  of  airborne  veapon 
systems. 

A  critical  event,  stochastic, 
compute (-assisted  l*nd  combat  model 
for  simulating  armor/anti -armor 
engageme  ts. 
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STATE  III  (SHAPE) 


TABLE  2-1  (CONT'D) 


CURRENT 

MODEL  (PROPONENT) 
STRAT  MSG  (USAF/SA) 

TACOS  II  ( ADS/DCD) 

WARRAMP-WCEM  (CAA) 

WASGRAM  (CNO) 


SIMULATION  MODELS  PERTINENT  TO  C3I 


PURPOSE 


A  computerized  analytical  general 
war  model  which  simulates  the  two- 
way  flow  of  multi -priority  messages 
between  the  NCA  and  forces, 

A  computeri zed ,  analytical  model 
designed  to  consider  th 
effectiveness  of  ground/air  defense 
and  penetrating  air  forces. 


A  computerized,  analytical,  limited 
war  model  of  two  forces  while 
considering  the  effects  of  command 
and  control,  logistics  and  close  air 
support. 

An  Interactive,  computer-assisted 
graphics  model  of  n.’val  warfare  used 
for  analysis  and  training. 
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The  game  is  Interactive  with  two  players  per  side  and  three 
persons  In  the  control  group.  The  players  are  at  division  and  brigade 
levels.  Player-generated  requests  and  orders  are  delayed  but  not 
degraded. 


This  model  was  the  first  to  link  command  and  control 
performance  to  battle  outcome  and  Is  the  basic  concept  which  has  been 
extended  to  fulfill  the  Phase  1  design  effort.  Variant  human  behavior 
Is  however  simulated  in  highly  aggregated  form  with  Insufficient 
resolution  for  the  current  purpose. 

2.1.2  FOURCE6 

FOURCE,  or  Command,  Control,  Communications,  and  Combat 
Effectiveness,  Is  a  division  level  force-on-force  combat  model  with 
resolution  to  battalion.  The  simulation  Is  a  two-sided  deterministic 
mathematical  model  which  executes  without  player  Intervention.  The 
purpose  of  the  simulation  is  to  evaluate  and  compare  manual  vs.  ADP- 
assisted  information  processing  within  the  division  in  terms  of  the 
battle  outcome. 

All  of  the  operations  and  intelligence  staffs  within  the 
division  are  simulated  as  either  manual-  or  ADP-assisted.  In  the 
manual  mode,  time  delays  are  introduced  to  reflect  successive  routing 
of  messages  through  manual  nodes.  These  time  delays  are  eliminated, 
for  the  most  part  in  simulated  ADP-assisted  staffs  although  querying 
times  are  considered.  Time  delays  are  computed  as  a  function  of 
processing  times,  workload  for  each  staff  element  a;<d  communication 
delays.  Processing  times  are  dependent  upon  report  type  not  report 
content.  Errors  are  not  introduced  into  the  report  content  but 
occasionally  a  report  is  lost.  Through  this  delay  process,  FOURCE  has 
been  able  to  distinguish  between  the  actual  battlefield  and  the* 
battlefield  as  the  staffs  at  various  echelons  perceive  It. 

Accordingly,  FOURCE  provides  a  significant  contribution  to 
the  state-of-the-art  in  the  modeling  of  command  and  control  in  combat 
simulations.  However,  the  current  effort  extends  the  concepts 
developed  for  FOURCE  in  that  it  is  interactive,  provides  for  higher 
resolution  and  will  model  variant  human  behavior  in  aggregate  form. 
FOURCE  may  be  used  to  validate  times,  etc,  but  that  is  Its  only 
practical  value. 


o  Command,  Control  /Communications  and  Combat  Effectiveness 
Model  Documentation,  Technical  Report  Vo T.  if,  TRASANA 
TMT7S7  6c;obeT*,  i§78 
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2.1.3  NETMAN7 

NETMAN  Is  a  non-interacti ve  digital  computer  model  which 
simulates  the  information  processing  actions  of  Army  personnel  during 
field  exercises  using  a  computer-based  message  handling  system.  The 
model  does  not  link  message  handling  effectiveness  with  battle 
outcome.  However,  it  does  place  particular  emphasis  on  certain  human 
performance  features  considered  to  be  Important,  e.g.,  operator 
stress,  speed,  precision,  and  level  of  aspiration.  In  simulating  each 
operator,  the  model  requires  as  input  an  estimation  of  time  related 
data  for  various  operator  tasks  to  be  accomplished.  The  overall  man- 
machine  performance  measure,  effectiveness,  Is  calculated  for  a 
simulated  exercise  and  summarized  over  the  total  exercise.  It  Is 
composed  of  four  independent  factors  —  thoroughness,  completeness, 
accuracy,  and  responsiveness. 

Q 

The  relationships  th&t  have  been  examined  using  HETMAN 
have  particular  relevance  to  this  effort  In  the  modeling  of 
lower-order  Information  processing,  in  that  various  message  handling 
parameters  are  related  to  operator  r;peed,  and  operator  precision. 
These  relationships  will  be  particularly  useful  In  defining  and 
validating  the  parameters  for  lower-order  processing  functions. 

2.2  REVIEW  OF  HUMAN  PERFORMANCE  IN  COMMAND  AND  CONTROL 

The  review  of  the  literature  on  human  performance  in 
command  and  control  tasks  or  functions  was  essentially  non-productive. 
Even  though  there  Is  a  prodigious  amount  of  literature  which  addresses 
the  many  and  varied  ramifications  of  human  performance,  only  a  small 
segment  of  it  is  directly  related  to  and  in  a  form  suitable  for  use  in 
the  design  of  simulations  of  command  and  control  processes.  Most  of 
the  relevant  error  analyses  were  highly  specific  studies  of  human 
performance  in  visual  detections  and  graphic  display  applications,  and 


7  'Siegel, 'A.  T77  Leaky,  V.  R. ,  and  Wolf,  J.  J.,  A  Computer 

Model  for  Simulation  of  Message  Processing  In  Military 
Exercise  Control  and  Evaluation  Systems,  ARt  Technical 
ReporT"TR-77  -A’2?, '  Oc  tbber  1977 — - 

8  Ibid. 
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during  operation  of  Input/output  devices.  The  control  factors  being 
examined  during  these  analyses  were  essentially  related  to  the 
environment,  stimuli  or  psychomotor  skills.  In  addition,  the  data 
from  these  studies  do  not  facilitate  linkage  to  show  Interactions, 
sequential,  or  combined  effects  on  combat  outcomes.  Another  relevant 
discovery  during  the  literature  review  was  that  error  analyses  were 
clustered  around  the  lower  skill  level  tasks  In  Information  processing 
functions  while  few  research  efforts  focused  on  variance  In  the 
cognition  or  decision  making  processes.  Accordingly,  the  literature 
did  not  provide  detailed  data  on  the  critical  dimensions  of  human 
performance  In  command  and  control  nor  did  It  provide  appproprlate 
parameters  describing  the  frequency,  etc,  of  such  performance. 

9 

However,  Gagne  did  provide  significant  Insight  and 
assistance  In  developing  the  models  for  staff  processing,  whether 
simulated  or  populated.  As  sncwn  In  Phase  1,  each  staff  process  will 
be  modeled  via  a  sequence  of  exclusive  events,  each  representing  a 
discrete  task  or  function  that  must  be  performed  to  complete  tr*e  staff 
process. 


Figure  2-1*°,  provides  a  simplistic  but  very  Intuitive 
model  of  human  functioning  which  has  been  used  to  extend  our  Phase  1 
efforts  to  provide  a  clear  and  logical  framework  to  link  staff  actions 
with  the  ongoing  “battle’1  within  the  simulation.  Gagne  reviews  human 
functions,  within  a  system,  as  a  sequence  of  transformations  which  the 
human  being  performs  upon  Inputs  to  produce  outputs.  His  ffodel  is 
directly  relevant  to  our  modeling  efforts  and  can  be  extended  to 
reflect  the  sequence  of  actions  that  occur  within  each  staff  module. 


9  Gagne,  Robert  H.  and  others.  Psychological  Principles  In 

System  Development.  (Hew  York:  Tfel t,  Rinehart  and  Winston,  1962). 

10  Ibid,  pg  54. 
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The  input  shown  on  the  figure  corresponds  to  the  messages 
received  by  an  individual  section  from  all  sources,  while  the 
instructions  relate  to  the  current  operating  procedure  for  that 
specific  module.  As  described  by  Gagne,  these  instructions  establish 
sets  in  short  term  memory  which  determine  the  shunting  conditions  and 
thus  the  level  of  functioning  at  which  the  i ndi v i dual  operates  in  the 
situation.  In  addition,  they  establish  the  filtering  conditions, 
which  determine  what  the  operator  senses  or  attends  to.  As  may  be 
readily  observed,  this  process  is  very  similiar  to  the  lower  order 
information  processing  tasks  inherently  required  of  a  division  staff 
section.  Finally,  there  are  inputs  to  this  process  from  long-term 
memory,  the  most  important  of  which  are  the  models,  which  make 
possible  comparisons  with  inputs  to  produce  perception,  and  the  rules, 
which  represent  courses  of  action  to  be  compared  in  the  thinking 
process.  The  sequences  in  which  these  actions  are  accompl Tshed  are 
also  stored  in  long-term  memory. 

The  fundamental  actions  which  are  of  primary  interest  are 
the  sensing,  perceiving,  and  thinking  functions.  According  to 
Gagne,1  sensing  is  a  function  which  "indicates  the  presence  or 
absence  of  a  difference  in  physical  energies".  For  our  purpose  this 
translates  to  the  recognition  of  an  incoming  tactical  message,  whether 
delivered  via  voice,  radio,  telephone,  hand,  teletype  or  data  link. 


Filtering  conditions  establish  attention  to  the  method  of  receipt, 
while  shunting  conditions  act  to  prevent  the  performance  of 
higher-level  functions  by  the  human  operator.  Lower  level  tasks 
usually  require  operators  to  receive  the  information  but  not  to 
interpret  its  meaning.  Perceiving  represents  the  next  level  in  the 
sequence  of  actions.  Here  the  individual  operator  produces  outputs 
which,  in  effect,  place  inputs  into  categories  whose  basis  is  their 
effect  rather  than  their  appearance.  In  other  words,  perceiving  is  a 
matter  of  identifying  the  meaning  of  inputs.  As  before,  instructions 
play  their  role  as  inputs  for  the  establishment  of  shunting  and 
filtering  conditions.  The  most  important  inputs,  however,  are  the 
models  from  long-term  memory  which  provide  standards  against  which 
inputs  are  compared.  The  last  in  the  sequence  of  actions  is  thinking, 
the  highest  level  of  human  functioning.  To  accomplish  this  function, 
an  individual  uses  rules  that  are  stored  in  long  term  memory  to 
generate  and  select  alternative  courses  of  action  in  order  to  generate 
output  or  decisions.  In  many  instances,  the  individual  must  transform 
the  existing  information  or  extrapolate  beyond  the  boundaries  of  the 
existing  information  to  produce  an  output,  again  based  upon  these 
models  stored  in  long-term  memory. 


n — 
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Gagne,  through  this  intuitive  mechanism,  has  represented  a 
basic  set  of  Inferences  that  must  be  considered  when  observing  the 
variety  of  behavior  possible  in  a  human  being.  We  find  this  model 
interesting  in  that  it  provides  a  basic  framework  for  examining  and 
isolating  the  human  activities  in  the  system  environment. 

2.2.1  Critical  Dimensions  in  Human  Performance 

12 

J.  S.  Kidd’s  contribution  to  Gagne's  book  provides 
additional  definition  to  the  model  In  terms  of  those  critical 
dimensions  that  affect  system  effectiveness.  Kidd  has  examined  the 
operator  in  complex  systems  for  the  purpose  of  identifying  which  of 
his  characteristics  are  germane  to  the  system  peformance.  The 
framework  he  used  also  Involved  the  specification  of  the  operator's 
role  or  function  In  the  system.  In  a  complex  Information-processing 
system,  Kidd  has  portioned  these  functions  into  two  categories 
~1  nforwatlon-processl ng  and  decision-making.  The  latter  category 
should  be  conceived  as  being  highly  dependent  upon  the  first;  that  is, 
the  quality  of  the  decision-making  is  dependent  upon  the  quality  of 
the  information  processes.  Kidd  has  defined  functions  that  belong  to 
each  category  and  these  definitions  have  been  used  to  fully  define 
each  elementary  operation  required  In  the  simulation  of  the  division 
staff  sections.  These  functions  are  arbitrary  and  are  not  Intended 
to  describe  completely  all  tasks  assigned  to  human  operations  within 
an  information-processing  system. 

A  summary  definition  of  each  category  and  the  functions 
included  with  each  is  presented  below: 

•  Information-Processing.  A  series  of 
actions  or  operations  involving  the 
communication  or  reception  of  data. 

-  Signal  Detection  and  Classification.  Detection  is  a 
matter  of  distinguishing  signal  inputs,  while 
classification  is  a  matter  of  distinguishing  among 
inputs. 

-  Recoding.  The  translation  from  signals  in  one  format 
to  signals  in  another. 

-  Accumulating  and  Summarizing.  The  collection  and 
manipulation  of  quantitative  and  qualitative  data 
to  keep  abreast  of  the  status  of  subordinate  units. 


12  Ibid,  pgs  159-183 
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-  Output-Processing.  The  classifying,  encoding,  and 
accumulation  of  generated  signals  or  information. 

-  Value  Weighting  and  Destination  Routing. 

The  determination  of  the  importance  and 
destination  of  information  to  be 
disseminated. 

•  Decision-Making.  The  action  of  producing  a 
choice  or  Judgement  from  one  or  more 
alternatives  based  upon  available 

information. 

Selection  and  Synthesis.  The 

interpretation  of  the  content  of  the 
input  to  include  the  operator's 

experience  with  respect  to  the 
consistency  and  veracity  of  alternative 
sources. 

Pattern  Construction.  Creating  a 
coherent  whole  out  of  discrete 
fragments. 

Cause-and-Effect  Attribution.  The 
assumption  or  determination  of  why 
the  situation  is  at  it  appears. 

Time-line  Analysis  and  Prediction. 

The  correlation  of  cause-attribution 
with  the  evaluation  of 
time-contingent  processes  in  the 
environment  to  extrapolate  to 
possible  outcomes. 

Cri tical -Cause  Selection*  The 
determination  of  what  factvors  in 
the  environment  can  be  manipulated 
and  the  priori  ti  zation  of  these 
factors.  This  leads  to  the  critical 
factor  that  must  be  manipulated  to 
most  directly  achieve  desired  goals. 

Action  Selection.  The  selection  of 
a  course  of  action  f**om  available 
alternatives  to  achieve  desired 
goal  s . 
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Effect  Evaluation.  The  assessment 
of  action  selection  upon  the 
environment  based  upon  feedback 
subsequent  to  action  Initiation. 


The  above  functions,  then,  define  the  critical  dimensions 
associated  with  human  performance  In  a  comnand  and  control  or 
Information-processing  system.  These  critical  dimensions  and  Gagne's 
model  provide  the  basic  framework  from  which  elementary  operations 
have  been  defined  and  sequentially  linked  to  encompass  all  those 
categories  of  action  that  must  be  completed  within  a  staff  section. 
Section  3.1  fully  addresses  this  modeling  effort. 

2.2.2  Classes  of  Human  Errors  In  Information  Processing  Systems 

During  the  review  of  the  literature,  there  was  one 
reoccurring  theme  -  to  err  Is  human.  Errors  are  an  expected  human 
phenomenon  and  the  research  emphasis  Is  on  studying  error  causing 
factors  In  various  combinations  to  determine  ways  in  which  to  minimize 
their  occurrence  or  effects. 

For  the  purposes  of  this  effort,  the  factors  and  the 
frequency  with  which  they  adversely  impact  human  performance  was  of 
interest.  The  literature  revealed  that  errors  may  be  Introduced  by 
any  number  of  factors,  but  the  frequency  with  which  they  occurred  was 
usually  related  to  specific  situations.  The  net  result  was  that  the 
factors  that  caused  errors  and  the  frequency  with  which  they  occurred 
were  not  available  in  a  form  relevant  to  the  modeling  of  variant  human 
behavior.* 


This  result  led  to  an  examination  of  how  errors  Impact  upon 
the  division  outcome.  This  Impact  can  be  partitioned  into  three 
categories: 

t  The  body  of  Information  on  which  the 

commander  and  his  staff  base  their  execution 
of  the  assigned  mission,  is,  or  becomes, 
wrong  or  misleading. 

•  The  commander  and  his  staff  fail  to  issue  the 
correct  orders  in  a  timely  manner  even  with 
adequate  resources  and  an  adequate  body  of 
information. 

•  The  commander  and  his  staff  issue  incorrect 
orders  even  with  adequate  resources  and  an 
adequate  body  of  information. 


*  However,  a  significant  portion  of  these  data  will  be 
helpful  in  the  design  implementation,  e.g.,  AD? 
formats,  dat3  base  entry,  etc. 
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These  three  categories  can  be  directly  attributed  to  human 
errors  on  the  part  of  the  commander  and  his  staff  and  readily  lend 
themselves  to  correlation  with  three  fundamental  reasons  for  their 
occurrence.  Specifically,  the  first  category  Is  brought  about  In  part 
by  the  cumulative  human  errors  In  the  way  1r,  which  the  body  of 
knowledge  1$  achieved  and  maintained,  i.e.,  errors  that  cause  the  body 
of  Information  on  which  decision-makers  base  their  execution  to  become 
wrong  or  misleading.  The  second  Is  mostly  attributable  to  human 
errors  In  management;  l.e.,  errors  that  lead  to  untimely  execution  of 
decisions,  ever  If  the  body  of  Information  Is  correct.  The  latter 
category  is  solely  attributable  to  human  errors  on  the  part  of  the 
decision-maker,  l.e.,  errors  that  lead  to  the  wrong  decisions,  even  If 
the  decisions  are  timely  and  based  upon  correct  information. 

This  reasoning  has  led  to  the  definition  of  three  classes 
of  human  error  In  Information  processing  systems: 

•  Data  errors  -  those  errors  that  Introduce 
erroneous  or  misleading  data  Into  the  data 
stream  and/or  the  staff  flles/dl splays,  e.g., 
the  location  of  the  2/84  Mech  Inf  is  plotted 
Incorrectly  on  the  G3  SITMAP  on  the  wrong  side 
of  the  WEGER  R. 

•  Procedural  errors  -  those  errors  that  delay 
the  completion  of  the  staff  action  by  making  a 
false  start  or  an  error  in  performance  of  an 
elementary  operation ,e .g. ,  G2  falls  to 
coordinate  *1th  G3  and  assigns  a  recce  mission 
to  the  cavalry  squadron  unaware  that  the 
squadron  has  been  assigned  a  screening  mission 
in  another  sector,  thereby  delaying  arrival  of 
cavalry  squadron. 

•  Cognition  errors  -  those  errors  that  cause  a 
faulty  tactical  decision  because  of  false  or 
incomplete  perception  of  the  available  data  or 
because  of  inadequate  action-selection 
criteria,  e.g.,  the  commander  misinterprets  an 
enemy  feint  as  the  main  effort  and  coimnts  his 
reserve  prematurely. 
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As  defined  above,  data  and  procedure  errors  are  directly  observable 
and  measurable.  This  is  true  since  the  information  stream/body  of 
knowledge  contains  a  reference  standard  from  which  to  observe  or 
measure  deviations  from  ground  truth  or  standard  operating  procedures. 
Cognition  errors,  on  the  other  hand,  are  not  directly  observable  and 
measurable  because  cognitive  processes  either  alter  existing 
information  or  generate  new  Information,  hence,  there  is  no  reference 
standard  for  comparison.  This  is  discussed  in  detail  In  Tlede’s1 
discussion  of  performance  measurement  In  military  information  systems. 

It  Is  readily  observed  that  these  three  classes  of  errors 
are  defined  to  be  mutually  exclusive.  This  Is  a  desired 

characteristic  which  allows  the  distribution  of  error  phenomena  over 
staff  processing  of  information  but  this  does  not  imply  that  each 
class  of  error  has  unique  impact  on  the  battle  outcome.  On  the 
contrary,  they  may  have  similar  Impacts  within  a  very  wide  range.  For 
example,  either  a  transposition  of  UTM  coordinates  (data  error)  or  a 
faulty  pattern  recognition  (cognition  error)  may  lead  to  an  erroneous 
prediction  of  an  enemy  breakthrough.  The  point  Is  that  the  impact  of 
these  errors  is  highly  situation  dependent  and  the  impact  upon  the 
battle  outcome  may  not  be  traceable  to  the  originating  class  except 
under  highly  controlled  experimental  conditions. 

2.3  CONCLUSIONS  ON  HUMAN  PERFORMANCE 

2.3.1  Existing  War  Gaming  Simulations 

Surprisingly,  there  was  only  one  war  gaming  simulation 
(FOURCE)  which  explicity  simulated  human  performance  in  command  and 
control  and  then  linked  the  performance  with  the  battle  outcome. 
However,  computerized  decision  rules  within  FOURCE  are  simplistic. 
Another  model  (NETMAN)  transformed  the  effects  of  fatigue,  stress, 
proficiency,  etc,  into  time-delays  in  the  decision-making  process,  but 
these  delays  were  not  related  to  the  battle  outcome  nor  were  the 


13 

Tiede,  R.  V.  On  the  Analysis  of  Ground  Combat,  p.  62  (MA/AH 
Publishing,  19791 
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various  effects  related  to  the  quality  of  the  decision.  The  one 
remaining  model  that  has  applicability  was  ADVICE  II.  This  simulation 
models  human  performance  for  the  lower  level  Information  processes  In 
highly  aggregated  form  and  employs  live  players  to  make  the  higher 
level  decisions.  Since  It  Is  an  Interactive  system,  the  battle 
outcome  reflects  both  the  timeliness  and  quality  of  the  decision 
process. 


Each  of  these  models  provides  insight  into  the  design  of 
the  Integrated  division-level  battle  simulation.  However,  the  actual 
design  will  be  extending  the  state-of-the-art  of  command  and  control 
and  war  gaming  simulations  by  providing  for  interactive  populated  and 
simulated  staff  models  and  by  linking  and  measuring  the  effects  of 
variant  human  performance  on  the  battle  outcome. 

2.3.2  Human  Performance  in  Command  and  Control 


Although  the  review  of  the  behavioral  science  literature 
was  essentially  non-productive  in  terms  of  the  objectives,  it  did 
provide  a  basic  model  for  Indicating  the  sequence  and  Interaction  of 
events  within  an  information  processing  system  and  helped  to  specify 
the  critical  dimensions  in  information  processing  and  decision  making. 

The  lack  of  substantive  data  on  the  type  and  frequency  of 
errors  led  to  a  determination  of  kinds  of  errors  which  Impact  upon  the 
battle  outcome.  This  in  turn  led  to  the  definition  of  three  classes 
of  error— data,  Drocedural ,  and  cogni tion--wh1ch  may  be  overlaid  on 
the  division-sta 7f  information  processing  functions  to  allow 
behavioral  scientists  to  examine  the  effect  of  human  staff  errors  on 
battle  outcome. 
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SECTION  3 


DELINEATION  OF  STAFF  PROCEDURES 


3.0  INTRODUCTION 


This  section  presents  an  analysis  of  Interactive 
simulations  that  focuses  on  the  detailing  of  division  staff  procedures 
and  Identification  of  the  procedural  step  points  at  which  one  or  more 
human  errors  might  occur.  The  analysis  begins  with  the  basic  building 
blocks  of  the  staff  procedures,  the  elementary  staff  operations 

performed  by  one  man.  These  fundamental  procedural  steps  are 
identified,  based  in  part  on  a  suggested  approach  from  another  study. 
The  detailing  of  the  procedures,  that  Is,  the  development  of  event 

thread  charts  composed  from  the  basic  building  blocks.  Is,  on  the 

other  hand,  based  solely  on  the  set  of  tactical  Information  messages 
already  defined  In  the  Phase  1  design.  Seven  such  charts  are 
presented  showing  the  staff  actions  either  as  the  Standing  Operations 
Procedures  ( SOPs )  to  be  followed  by  players  in  live  staff  modules  or 
as  the  Class  1  event  sequence  In  the  simulated  modules.  The  seven 
charts  cover  the  420  different  staff  processes  stemming  from  the 

standard  tactical  messages.  The  section  Is  concluded  with  a  matrix 
showing  the  procedural  step  points  at  which  the  various 
classifications  of  human  errors  can  occur.  The  error  classifications 
are  those  from  Section  2. 

The  analytical  framework  developed  in  this  section  is 
applied  to  the  design  of  simulated  staff  modules  in  Section  4  which  in 
turn  forms  the  basis  for  the  discussion  of  task  assignments  in  Section 
5. 


3.1  ELEMENTARY  STAFF  OPERATIONS 

The  Phase  1  design  combined,  for  the  first  time,  command 
and  control  processes  executed  by  human  players  in  live  staff  modules 
with  the  simultaneous  simulation  of  the  same  processes  in  other,  but 
now  simulated,  staff  modules.  Depending  on  the  selected  configuration 
of  play,  simulation  represented  an  interactive  war  game  from  the  point 
of  view  of  the  populated  modules  and  a  simulation  of  decision-making 
processes  from  the  point  of  view  of  the  simulated  staff  modules. 
However,  no  documents  were  found  In  the  literature  which  treated  these 
more-or-less  separate  areas  jointly.  Earlier  efforts  and  other 


3-1 


studies  have  provided  Ideas  and  approaches  for  the  design  of  an 
Interactive  war  game.  Similarly,  but  in  a  different  vein,  alternative 
approaches  to  the  simulation  of  decision-making  processes  have  yielded 
some  Insights  Into  the  problem  of  simulating  human  staff  performance. 
Consequently,  the  material  here,  which  identifies  the  elementary  staff 
operations  common  to  both  the  live  staff  procedures  and  the  computer 
logic  for  simulating  staff  processes,  Is  largely  unexplored  territory. 

concept  of  elementary  operations  originated  in  an 
earlier  study  of  staff  processes.  This  study  used  an  event-oriented 
simulation  of  the  staff  actions  to  determine  the  sequence  of 
operations,  the  time  required  for  each  step,  the  time  spent  In  queue, 
the  staff  member  who  performed  each  operation,  and  the  station  at 
which  each  operation  was  performed.  The  approach  Involved  breaking 
staff  processes  down  Into  a  series  of  elementary  operations  such  as 
those  listed  In  Table  3-1.  The  study  Itself  provided  some  insights 
into  human  staff  performance,  but  the  simulation  did  not  address  the 
actual  tactical  Information  content  of  the  staff  actions  being 
processed. 


A  similar  approach  has  been  adopted  here  but  this  time  it 
has  been  extended  to  Include  the  Information  content.  The  staff 
processes  Invoked  by  the  standard  tactical  messages  In  the  Phase  1 
design  have  been  broken  down  into  a  series  of  elementary  staff 
operations,  where  each  such  operation  is  performed  by  one  man. 
Furthermore,  In  order  to  provide  a  basis  for  the  task  design  for 
Interactive  simulations,  each  elementary  operation  identified  has  an 
associated  process/sklll  level  required  of  the  man  who  performs  the 
operation.  These  levels  were  affixed  by  the  following  argument: 


1  Tlede,  R.V.,  Walker ,M.  E.,  $tenstrom,D.  0.,  and  Sweeny,  S.  0. 
The  Integrated  Battlefield  Control  System  (IBCS)  Third 
Refinement  Study , (Mrlear, ,  Va . ,  Science  Appl  ications,  Inc . : 
Pinal  Report,  March  1975) 
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TABLE  3-1.  ELEMENTARY  OPERATIONS 


THRT3UGHPUT  OPERATIONS 

Receive  Radio  (Rev  Rad):  All  action  steps  required  to  produce 
a  written  copy  of  an “T ricbmi ng  message  via  radio  to  include  re¬ 
quired  radio  operating  procedures. 

Receive  Telephone  (Rcy  TP ) :  All  action  steps  required  to 
produce  a  written  copy  of  an  incoming  message  via  tele¬ 
phone  to  include  required  telephone  operating  procedures. 

Receive  RATT  (Rev  RATT):  All  action  steps  required  to  produce 
a  written  copy  of  an  Incoming  message  via  RATT  to  include 
required  RATT  operating  procedures. 

Receive  Aurally  (Rev  Aur):  Reduction  of  an  oral  transmission 
to  a  written  form. 

Transmit  Orally  (Xmlt  Oral):  All  action  steps  required  to 

convey  a  written  message  by  unaided,  human  voice  to  a  pre¬ 
designated  addressee(s) . 

Plot  on  Map  (Plot):  Post  or  update  symbols  on  map. 

Enter  in  Journal  (Enter):  Physical  process  of  recording  in 
journal ,  workbook  or  list. 

Retrieve  (Rtrv);  (Must  be  associated  with  a  specific  file  or 
display.)  Locating  and  extracting  from  a  particular  file  or 
displ  ay. 

Compose:  Prepare  a  draft  of  a  product  or  portion  of  a  product. 
Make  Overlay  (Overlay):  Physical  preparation  of  map  overlay. 
Post  Display  (Post):  Enter  or  update  data  on  visual  display. 
BRANCHING  OPERATIONS 

Determine  Internal  Routing  (DIP):  Read  for  content  and  select 
addressee/station  routing  within  element  for  further  processing 
of  that  product. 


wm 
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TABLE  3-1.  ELEMENTARY  OPERATIONS  (CONT’D) 


Determine  External  Routing  (PER):  Read  for  content  and  select 
external  addresseef s) . 

Reproduce,  Manual  (Repro,  Man):  Production  of  an  exact  hand¬ 
written  copy  (may  be  multiple  copies  using  carbon  paper). 

Reproduce,  Machine  (Repro,  Mach):  Production  of  an  exact  copy 
(or  copies)  utilizing  copy  machine. 

Type:  Production  of  an  exact  copy  using  a  typewriter.  (May  be 
multiple  copies  using  carbon  paper.) 

COLLECTION  OPERATIONS 

Consolidate  and  Approve  (C&A):  Accept,  Integrate,  edit 

portions  of  a  product  produced  “by  more  than  one  source  and 
release  final  product  for  distribution  (normally  to  external 
addressees).  The  same  operation  Is  used  for  approval  only  in 
which  case  there  Is  a  single  input. 

TERMINATING  OPERATIONS 

File:  (Must  be  associated  with  a  specific  station.)  To  place 
a  product  or  extract  therefrom  In  a  designated,  closed  (non¬ 
display)  storage  place  or  to  update  a  permanent  (nondisplay) 
record. 

Terminate  (Term):  This  copy  goes  no  further  and  is  placed  in 
Pile  l3  or  convenience  file. 

Transmit  Radio  (Xmit  Rad):  All  action  steps  required  to  convey 
a  written  message  via  radio  to  a  predesignated  addressee  to 
include  required  radio  operating  procedures. 

Transmit  Telephone  (Xmit  TP):  Ml  action  steps  required  to 
convey  a  written  message  via  telephone  to  a  predesignated 
addressee  to  include  required  telephone  operating  procedures. 

Transmit  RATT  (Xmit  RATT):  All  action  steps  required  to 
convey  a  written  mess age "via  PATT  to  a  predesignated  addressee 
to  include  required  RATT  operating  procedures. 


Transmit  Courier  (XmitCour):  Picking  up  an  action  from  an 

outbox ,  courier,  other staff  member,  or  self  and  delivering 
it  to  a  predetermined  addressee/station  or  his  Inbox. 


3-4 


"Figure  3-1  Is  a  representation  of  a  series  of  processes 
such  as  a  decision  node  carries  out  on  Information  flowing  through  the 
node.  At  the  bottom  of  the  figure  is  an  external  Information  stream-- 
the  communications  network --which  the  node  taps  and  to  which  It 
contributes.  Six  progressively  more  complex  processing  levels  are 
depicted.  The  information  that  flows  up  from  the  external  stream  must 
first  be  received,  a  Level  I  or  communications  process.  The  received 
information  In  a  tactical  military  system  is  In  the  form  of  orders 
(plan'..),  summaries,  reports,  queries,  or  requests.  These  must  be 
tagged,  sorted,  recorded  (think  of  the  large  nunber  of  telephone  and 
voice  radio  inputs),  and  used  to  update  files;  much  of  It  Is  also 
displayed  on  situation  maps  or  totes.  The  composite  of  these 
processes  may  be  called  Level  II  or  message  center  and  filing 
processes.  The  Level  II  processes  produce  a  data  base,  some  part  of 
which  is  in  the  form  or  visible  displays  for  ready  reference.  It  is 
pertinent  to  comment  in  passing  that  the  graphical  representation  of 
certain  kinds  of  Information  on  a  situation  map  is  the  substitute  for 
the  hill  overlooking  the« battlefield  and  for  helicopters  when  the 
latter  cannot  fly  or  see." 

"The  next  four  process  levels  use  the  f.les  in  successively 
more  complex  ways.  Note  that  they,  too,  update  the  files,  but  these 
updates  are  more  in  the  nature  of  manipulations  on  the  basic  data 
added  by  Level  II.  These  utilization  processes  begin  with  Level  III, 
selective  retrieval  of  information  from  the  files.  At  Level  IV,  such 
data  are  aggregated  by  means  of  a  priori  rules,  which  may  vary  from 
simple  arithmetic  combinations  to  more  sophisticated  rules  of 
combination  such  as  the  appearance  of  three  or  four  maneuver 
battalions  operating  in  the  same  area  triggers  the  search  for  their 
associated  fire  and  service  support  elements.  The  important 
consideration  is  that  the  rules  for  aggregation  have  been  determined 
in  advance  and  are  stored.  Process  Level  Y  al  *»c  aggregates  data,  but 
the  rules  for  aggregation  are  devised  by  the  user  In  real  time--that 
is,  he  hypothesizes,  through  pattern  recognition,  new  and  higher  level 
interpretations  of  the  data  being  presented.  For  example,  the  rapid 
increase  In  density  of  artillery  in  a  given  sector  Is  interpreted  as 
an  indicator  of  enemy  intent  to  attempt  a  breakthrough  in  that  sector. 
Process  Level  V  may  also  be  accomplished  in  a  succession  of  stages 
that  amounts  to  piling  hypotheses  one  on  top  of  another.  Furthermore, 


2  Tiede,  R.  Y.,  On  The  Analyis  Of  Ground  Combat, (  Military  Affairs/ 
Aerospace  Historian  Publishing,  1978). 
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data  aggregations  may  be  extrapolated  forward  In  time.  This  amounts 
to  yet  another  hypothesis  formulation  of  a  different  type;  assumptions 
are  made  about  observed  rates  and/or  accelerations.  For  example, 
examination  of  present  positions  and  rates  of  advance  for  both  sides 
leads  to  a  prediction  that  the  main  battle  will  occur  at  point  Y  at 
time  T„  Level  V  produces  what  is  commonly  called  perception.  At  the 
highest  level,  Level  YI,  data  aggregations  are  compared  and  evaluated, 
and  one  or  more  are  selected.  This  last  is  the  culmination  of  the 
decision  process. 

3.1.1  Definitions  of  the  Elementary  Operations 

The  elementary  staff  operations  for  the  division-level 
battle  simulation  are  presented  in  Table  3-2.  The  staff  procedures  to 
be  followed  by  players  in  populated  modules  are  structured  out  of 
these  27  basic  procedural  steps.  Correspondingly,  the  event  threads 
in  the  computer  simulation  of  staff  processes  are  composed  from  these 
Class  1  events. 

The  elementary  operations  fall  into  two  broad  groups  in  a 
manner  suggest  by  J.  S.  Kidd  .  According  to  Kidd,  the  tasks  allocated 
to  human  operators  within  a  general  man-machine  system  fall  into  the 
two  categories  of  information-processing  and  decision-making.  While 
the  line  of  demarcation  between  the  two  categories  is  somewhat  obscure 
and  arbitrary,  the  table  groups  the  elementary  operations  of  Levels  I, 
II,  III  and  IV  in  the  information-processing  category  and  those  at  the 
higher  levels  under  decision-making.  Furthermore,  under  these 
categories,  the  individual  definitions  contain  italicized  references 
to  Kidd's  task  descriptions,  where  applicable.* 

In  this  table  and  the  discussion  following,  the  short  word 
"chops"  is  used  to  mean  request  for  concurrence. 

One  point  should  be  made  about  the  dual  purpose  table.  The 
elementary  operations  defined  are  ordinarily  understood  to  be  one-man 
tasks  whether  they  are  interpreted  as  procedural  steps  in  a  live  staff 


3  Ibid. 

4  Gagne  Robert  H.,  and  others,  Psychological  Principles  in  System 

Development  (New  York:  Holt,  Rinehart,  and  Kinston,  1$62.) 

*  Kidd's  task  descriptions  were  oriented  to  radar  man-machine 
systems.  It  Is  remarkable  that  the  same  task  descriptions  are 
applicable  to  corpo-  or  division-level  command  and  control 
systems. 
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TABLE  3-2 


DEFINITIONS  OF  THE  ELEMENTARY  OPERATIONS 


E.O.  PROCESS ,/ SKILL 

DESCRIPTOR  LEVEL 


DEFINITION 


Information-Processing 
INITIATE  8Y  CLOCK  I 


RECEIVE  (or  ACCEPT)  I 


TRANSMIT  (or  DELIVER)  I 


DERI 


II 


DER2 


II 


Start  a  staff  action  whose  out¬ 
put  is  due  at  a  prescribed 
clock  time  by  SOP. 

Signal  detection  and  Classification. 

RECEIVE:  transform  oral  com¬ 
munications  received  by  radio 
or  telephone  into  a  hand  written 
message,  making  one  or  more 
copies  at  the  time.  ACCEPT 
(subsumed  under  RECEIVE): 
accept  a  hand  written/printed 
message  delivered  by  a  courier. 
Signal  detection  arid  Classifi¬ 
cation. 

TRANSMIT:  transform  a  hand 
written  message  into  oral  com¬ 
munications  on  a  radio  or  tele¬ 
phone.  DELIVER  (subsumed  under 
TRANSMIT):  hand  over  a  written 
message  to  a  courier  or  hand 
carry  the  message  to  its  ad¬ 
dressee.  Output-Processing. 

Determine  the  external  routing 
of  a  received  message.  “ External'1 
means  outside  the  staff  section 
including  other  staff  sections, 

Corps  and  adjacent  headquarters , 
but  not  subordinate  units  in 
the  BOG.  Value  Weighting  and 
Destination  Routing. 

Determine  the  external  routing 
for  information  copies  of  a 
message  generated/processed  in 
the  staff  section.  In  this  case 
"externa  1"  means  outside  the 
staff  section,  including  other 
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TABLE  3-2  (CONT'D) 


staff  sections,  Corps  and  ad¬ 
jacent  headquarters  as  well  as 
subordinate  units  in  the  BOG. 
Output-Processing. 


DIR1 

II 

Determine  the  precedence  for 
message. .pracessing  and  the  in¬ 
ternal  routing  for  the  purpose 
of  updating  the  staff  files/ 
di spl ays .  Va lue  Weighting  and 
Destination  Routing. 

DIR2 

II 

Determine  the- internal  routing 
for  generated/processed  messages 
for  the  purpose  of  filing/posting 
output- reports. -  Output-Processing , 

ENTER 

II 

Log  in  the  receipt/ transmittal 
of  a  message.  Accumulating 
and  Summarizing. . 

FILE 

II 

Place  a  received/generated 
message,  or  elements  thereof, 
in  the  appropriate  staff  file. 
Accumulating  and  Summarizing. 

MAKE  COPIES 

II 

Reproduce  copies  of  a  written 
message,  as  required. 

COMPOSE 

III 

Prepare  in  draft  or  final  form 
an  output  query,  report,  or 
frag  order  based  on  the  action 
^election  made  by  the  decision¬ 
maker.  Output-Processing . 

DECOMPOSE 

III 

Extract  from  a  received  message 
data  elements  relevant  to  the 
functions  of  the  staff  section. 
Recoding . 

DETERMINE  COGNIZANCE 

III 

Determine  the  area  of  responsi¬ 
bility  for  the  action  selection 

made  by  the  decision-maker. 

The  subsequent  processing  of 
the  action  should  be  switched 
if  the  area  of  responsiblivy 
is  outside  the  purview  of  the 
staff  section.  Qi.tput-Processing . 
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POST  (or  PLOT) 

RETRIEVE 

COORDINATE  W.  STAFF 

COORDINATION  COMPLETE? 

Decision-Making 

EVALUATE  IN  CONTEXT 

INITIATE  BY  SELF 


HI  POST:  transfer  oral  or  written 

data  onto  a  graphic  display  or 
status  board.  PLOT  (subsumed 
under  POST):  transfer  onto  a 
scaled  situation  map.  Recoding . 

HI  Withdraw  a  received/generated 

message  from  its  appropriate 
staff  file.  Output-Processing. 

IV  Determine  whether  the  action 

selection  made  by  the  decision¬ 
maker  should  be  approved  by  the 
Commander  and/or  coordinated 
with  other  staff  sections  prior 
to  its  release.  Subsequent 
processing  of  the  action  should 
be  switched  if  approval  or  co¬ 
ordination  is  determined  to  be 
required.  Action  Selection . 

IV  Determine  whether  concurring 

responses  have  been  received 
from  all  sections  to  which  chops 
requests  were  submitted.  Effect 
Eve luation . 


V  Determine  whether  the  received 
message  generates  the  require¬ 
ment  for  formal  staff  action 
at  this  time.  The  determina¬ 
tion  may  be  based  on  the  message 
content  alone  or  on  a  trigger 
criteria  existing  for  certain 
type  messages.  If  formal  staff 
action  is  determined  not  to  be 
required  at  this  time,  the 
action  processing  terminates. 
Selection  and  Synthesis . 

V  Initiate  formal  staff  action  based 
on  perception  of  situation  or  pro¬ 
blem  held  in  the  mind  of  the  init¬ 
iator. 

Selection  and  Synthesis* 
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SYNTHESIZE  DATA  V 


EVALUATE  DATA  V 


CONSTRUCT  PATTERN  V 

EXTRAPOLATE  SITUATION  V 

GENERATE  ALTERNATIVES  V 

ESTABLISH  CRITERIA  VI 

EVALUATE  ALTERNATIVES  VI 

SELECT  ACTION  VI 


Generate  from  the  available  data 
a  picture  or  perception  of  the 
situation  or  problem. 

Se  lection  and  Synthesis » 

Determine  whether:  (1)  the  un¬ 
certainties  of  the  perception 
warrant  the  pursuit  of  more  in¬ 
formation  before  proceeding  with 
the  action;  (2)  the  perception 
warrants  immediate  action;  or 
(3)  the  perception  warrants  both 
of  the  above. 

Effect  Evaluation , 

Complete  the  picture  or  pattern 
by  hypothesizing  the  missing  or 
unknown  elements. 

.Pattern  Construction, 

Interpret  the  situation  by  extra¬ 
polating  the  time  relationships 
inherent  in  the  perception. 

Time -  line  Ana  lysis  and  Prediction , 

Postulate  two  or  more  alternative 
courses  of  action  which  address  the 
analyzed  situation  or  pattern. 
Cai/se-and-effect  attribution  and 
Tijne-line  Analysis  and  Prediction, 

Formulate  the  weighting  factors  to 
be  used  in  comparing  the  alternative 
courses  of  action. 

Critical  Cause  Selection . 

Rank  the  alternative  courses  of 
action  by  applying  the  weighting 
factors. 

Critical  Cause  Selection , 


Select  the  best  course  of  action 
from  the  postulated  alternatives. 
If  no  more  than  one  alternative 
has  been  generated,  the  selection 
is  entirely  automatic. 

Action  Selection, 
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module  or  as  Class  1  events  in  a  computer  simulation  of  the  staff 
processing.  The  strict  interpretation  as  one-man  tasks, 
however , breaks  down  in  the  case  of  two  Level  V  operations:  EVALUATE 
IN  CONTEXT  and  SYNTHESIZE  DATA.  In  a  live  staff  module,  these 
procedural  steps  will  ordinarily  be  performed  by  the  senior  staff 
officer  himself.  But  both  operations  call  for  accessing  tactical 
information  from  the  staff  section  files/displays  in  order  to  evaluate 
the  received  message  in  context  or  to  generate  a  picture  or  perception 
of  the  situation.  The  senior  officer  in  a  live  module  may  request 
assistance  in  these  accessing  subtasks  from  other  subordinate  staff 
players.  Consequently,  the  one-man  task  rule  breaks  down  In  the  live 
staff  procedures. 

Consider  as  an  example  the  staff  processing  that  would  take 
place  if  the  G3  were  to  receive  a  chop  request  from  G2  regarding  the 
proposed  use  of  air  cavalry  helicopters  for  a  post-strike  damage 
survey.  It  will  be  shown  in  the  next  subsection  that  the  G3,  under 
these  circumstances,  would  perform  the  following  sequence  of 
operations  preparatory  to  responding  to  G2:  SYNTHESIZE  DATA,  EVALUATE 
DATA,  CONSTRUCT  PATTERN,  EXTRAPOLATE  SITUATION,  GENERATE  ALTERNATIVES, 
EVALUATE  ALTERNATIVES,  and  SELECT  ACTION.  The  G3  would  emerge  from 
the  last  of  these  operations  with  the  basic  decision  whether  or  not  he 
concurred  with  the  modified  mission  for  the  air  cavalry  elements.  The 
sequence  of  operations,  however,  would  begin  with  one  of  the  Level  V 
steps  mentioned  above.  In  a  live  G3  module,  the  senior  operations 
officer  might  very  well  request  the  help  of  the  assistant  operations 
officer  or  the  operations  sergeant  in  assembling  the  information  about 
the  current  status  and  missions  of  the  air  cavalry  troop  prior  to  his 
analyzing  the  situation.  In  this  instance,  it  is  clear  that  the 
SYNTHESIZE  DATA  step  is  not,  strictly  speaking,  a  one-man  operation. 

In  a  simulated  staff  module,  on  the  other  hand,  the 
interpretation  of  the  one-man  operations  will  be  followed  In  the 
strictest  sense.  The  computer  will  simulate  the  staff  processing  of 
the  receipt  of  a  chops  request  like  that  above  as  though  the 
elementary  operations  involved  were  each  performed  by  a  single 
individual.  It  will  be  shown  in  Section  4  that  this  rigid  rule 
provides  the  basis  for  simulating  the  chance  occurrences  of  human 
error  phenomena  in  the  staff  processing. 

3.1.2  Class  1  Events 

The  definitions  of  the  elementary  operations  given  in  Table 
3-2  provide  a  basis  for  completing  the  list  of  Class  1  events 
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specified  in  the  Phase  1  design.  In  the  general  event-oriented 
simulation  structure,  Class  1  events  were  defined  as  the  staff 
processing  events  the  structured  sequences  of  which  gave  the  basic 
logic  for  simulated  staff  modules.  The  report  stated  that  all  the 
different  event  threads  reflecting  the  staff  processing  would  contain 
"an  internal  trigger,  or  starting,  Class  1  event,  and  one  or  more 
terminating,  or  ending,  Class  i  events.  The  number  of  events 
simulated  between  the  trigger  and  terminating  actions  steps  will 
depend  on  the  individual  action  SOPs  and  on  the  level  of  detail  used 
in  simulating  the  staff  action."  The  definition  of  the  elementary 
operations  now  fix  the  level  of  detail,  and  the  intermediate  Class  1 
events  can  be  added  to  the  original  table  (Table  4-3  in  the  Phase  1 
report) . 


Table  3-3  shows  the  now  complete  list  of  Class  1  events  in 
the  basic  design  concept  for  the  battle  simulation.  The  event  numbers 
shown  in  the  Table  are  based  on  the  convention  adopted  for  that 
design.  The  following  points  should  be  noted  about  the  Class  1 
events: 

•  Event  No.  100  corresponds  to  the  elementary  operation 
INITIATE  BY  CLOCK. 

•  Event  Nos.  101  thru  112  are  all  variations  of  one 
elementary  operation  RECEIVE. 

t  Event  Nos.  189  thru  199  are  all  variations  of  one 
elementary  operation  TRANSMIT. 

•  The  remainder  of  the  events  in  the  table  are,  with  one 
exception,  in  one-to-one  correspondence  with  the 
remaining  elementary  operations  in  Table  3-2*. 

•  The  one  elementary  operation  for  which  no  Class  1  event 
has  been  defined  is  INITIATE  BY  SELF.  This  exception 
is  discussed  iurther  in  Section  4. 

It  should  be  noted  further  that  these  Class  1  event 
definitions  may  be  modified  when  the  question  of  variable  interface 
boundaries  is  addressed.  As  will  be  seen  in  the  next  subsection,  one 


*  The  event  numbers  for  these  Class  1  Events  are  so  chosen  that  they 
provide  ready  identification  of  the  process/skill  level  associated 
with  the  elementary  operation.  Thus  Event  Nos.  121  thru  127  are 
Level  II,  Event  Nos.  130  thru  134  Level  III,  etc. 


3-13 


TABLE  3-3.  CLASS  1  EVENTS 


EVENT  NUMBER 

DEFINITION  OF  THE  EVENT 

Internal  Triqgers 

* 

100 

Clock  indicates  that  it  is  time  to  initiate  staff  action. 

101  . 

Receive  a  tactical  information  message  from  BOG  or 
higher  HQ. 

102 

Receive  a  retransmitted  copy  of  input  to  another  staff 
section. 

103 

Receive  an  info  copy  of  output  by  another  staff  section. 

104 

Receive  a  query  from  another  staff  section. 

105 

Receive  a  request  for  concurrence  from  another  staff 
section. 

106 

Receive  a  request  for  consideration  from  another  staff 
section. 

107 

Receive  a  concurring  response  to  a  request  for 
concurrence. 

108 

Receive  a  non-concurring  response  to  a  request  for 
concurrence. 

109 

Receive  a  decision  from  the  Commander. 

110 

Receive  a  non-concurring  response  to  a  request  for 
consideration. 

111 

Receive  a  response  to  its  query  to  another  staff  section. 

112 

Action  Steps 

Receive  information  from  another  staff  section. 

121 

Determine  external  routing  of  retransmittal  copies 
(DERI). 

122 

Determine  external  routing  of  information  copies  of 
output  (DER2) . 

123 

Determine  precedence  for  processing  and  internal 
routing  for  files/displays  update  (DIR1). 

124 

Determine  internal  routing  for  section  copy  update 
(DIR2). 

125 

Log  in  receipt/transmittal  of  all  input/output  messaqes. 
(ENTER). 

126 

Place  received/generated  message,  or  elements  thereof, 
in  appropriate  section  files  (FILE). 

127 

Reproduce  copies  of  a  message  (MAKE  COPIES). 
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Action  Steps  ( 

130 

131 

132 

133 

134 

140 

141 

150 

151 

152 

153 

154 

155 

163 

164 

165 

Terminators 

189 

190 

191 

192 

193 

194 

195 


Prepare  output  message  in  draft  or  final  form  (COMPOSE), 

Extract  from  received  message  selected  data  elements 
relevant  to  staff  section  function  (DECOMPOSE). 

Determine  area  of  responsibility  for  the  selected 
action  (DETERMINE  COGNIZANCE). 

Transfer  data  onto  a  status  board  or  graphic  display 
(POST  or  PLOT). 

Withdraw  received/generated  message  from  appropriate 
section  files  (RETRIEVE). 

Determine  requirements  for  Conmander’s  approval  or 
staff  coordination  (COORDINATE  W.  STAFF). 

Determine  whether  concurring  responses  cover  all  staff 
sections  solicited  (COORDINATION  COMPLETE?) 

Determine  if  formal  staff  action  required.' at  this 
time  (EVALUATE  IN  CONTEXT). 

Generate  perception.  (SYNTHESIZE  DATA). 

Determine  if  more  information  required  (EVALUATE  DATA). 

Complete  pattern  by  hypothesizing  the  missing  or 
unknown  elements  (CONSTRUCT  PATTERN). 

Interpret  the  situation  by  time-line  extrapolation 
(EXTRAPOLATE  SITUATION). 

Postulate  two  or  more  courses  of  action  (GENERATE 
ALTERNATIVES). 

Formulate  weighting  factors  for  comparing  alternatives 
(ESTABLISH  CRITERIA). 

Rank  the  alternatives  by  applying  the  weighting 
factors  (EVALUATE  ALTERNATIVES). 

Select  the  course  of  action  (SELECT  ACTION). 


Send  to  selected  staff  elements. 

Issue  frag  order  or  warning  order. 

Initiate  query. 

Initiate  a  request  for  concurrence. 

Initiate  a  request  for  consideration. 

Initiate  a  report  for  higher  headquarters. 
Aggregate  information  on  file  for  a  response. 
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Terminators  (Conttd) 

196  Issue  a  concurring  response  to  a  request  for  con¬ 
currence. 

197  Issue  a  non-concurring  response  to  a  request  for 
concurrence. 

198  Issue  a  non-concurring  response  to  a  request. 

199  Retransmit  copies  of  input. 


approach  to  eliminating  the  low-level,  repetitive  staff  operations  Is 
simply  to  combine  the  Level  II,  III  and  IV  tasks  In  a  staff  action 
under  the  Level  I  trigger  event  or  under  the  Level  I  terminating  event 
associated  with  the  action.  This  would  mean  that  the  live  modules  and 
simulated  modules  alike  would  be  Implemented  by  means  of  Class  1  Event 
Nos.  LOO  thru  112  as  triggers  and  Event  Nos.  189  thru  199  as 
terminators,  but  that  these  events  would  have  broader  definitions 
covering  the  Level  II,  III  and  IY  steps  Involved.  The  sequences  of 
Class  1  events  spelling  out  the  lew-lev el  events  that  could  thus  be 
eliminated  are  presented  in  the  next  subsection.  The  logical  design 
Implications  are  developed  in  the  companion  report.  On  the  Design  of 
Simulations  of  Command  and  Control  Processes. 

3.2  EVENT  THREAO  CHARTS  FOR  STAFF  PROCESSING 

The  logical  sequences  of  events  that  make  up  the  simulated 
battle  were  presented  in  Design  Note  J  of  the  Phase  1  design. 
Separate  event  thread  charts  were  given  for  each  standard  tactical 
information  message  that  was  involved  in  the  command  and  control  of 
the  Blue  division-level  forces.  The  charts  were  composed  from  the  six 
classes  of  events  that  formed  the  basic  structure  of  the  model. 

The  event  v hr rad  charts  were  necessarily  incomplete  In  one 
respect.  Although  they  showed  the  Class  1  trigger  events  that  started 
the  staff  processing  associated  with  a  tactical  information  message 
and  the  Class  1  terminating  events  that  ended  the  staff  actions,  they 
did  not  reflect  the  internal  action  steps  between  the  starters  and  the 
terminators. 

The  elementary  operations  and/or  Class  1  events  set  forth 
in  the  previous  subsection  now  provide  a  basis  for  developing  the 
complete  event  thread  charts  for  the  staff  processing  represented  in 
simulated  staff  monies  as  well  as  the  corresponding  SOPs  to  be 
established  for  players  in  live  staff  modules.  The  charts  serving 
these  two  parallel  purposes  are  presented  here. 

3.2.1  Categorization  of  Staff  Procedures 

Within  the  spectrum  of  the  standard  tactical  messages 
specified  in  the  Phase  1  design,  there  are  405  different  staff 
procedures  involving  unique  Input/output  messages  and  unique  staff 
sections.  There  are  also  15  additional  staff  actions  In  which  the 
senior  officer  in  a  staff  section  initiates  formal  staff  action 
because  he  spontaneously  perceives  that  It  Is  required  forthwith 


3-17 


(INITIATE  BY  SELF).  The  resulting  420  staff  procedures  provide  the 
basis  for  the  categorization  of  staff  procedures  and  the  event  thread 
charts  for  staff  processing. 

The  seven  (7)  categories  of  staff  actions  to  which  this 
family  of  420  procedures  reduced  are  shown  in  Table  3-4.  The  table 
shows  that  for  each  of  seven  (7)  different  kinds  of  action$--each 
identifiable  by  the  manner  with  which  it  is  triggered--there  is  a 
separate  sequence  of  procedural  steps  (or  Class  1  events) 
characterizing  the  staff  processing.  The  trigger  events  are  those 
listed  in  Table  3-3. 

The  event  thread  charts  for  the  seven  categories  are 
presented  in  the  following  paragraphs. 

3.2. 1.1  Category  1  Actions 

The  first  category  of  staff  procedures  covers  all  actions 
triggered  by  the  receipt  of  a  Class  4  input  message  from  the  BOG,  or 
higher  or  adjacent  headquarters.  The  event  thread  chart  is  shown  in 
Figure  3-2. 


This  chart  and  the  ones  to  follow  are  based  on  the  event 
thread  method  of  specifying  the  sequence  of  events  and/or  procedural 
steps  involved  in  the  simulation.  The  circles  represent  defined 
events.  The  arrows  connecting  successive  events  represent  the  passage 
of  time.  Here  the  events  themselves  contain  the  following  identifying 
information : 

•  The  Class  1  event  number  (from  Table  3-3). 

•  The  elementary  operations  descriptor  from  (Table 
3-2). 

•  The  process/skill  level  of  the  operation 
(also  Table  3-2). 


All  charts  are  Intended  to  serve  two  separate  purposes.  First,  they 
specify  the  basic  logical  structure  to  be  used  in  the  simulated  staff 
modules.  Second,  they  give  the  staff  action  SOPs  for  player  roles  in 
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TABLE  3-4 


STAFF  ACTION  CATEGORIES 

Intersection  of  Tactical  Information  Messages  and  the  Staff  Modules 


Category 

Triggered  By 

No  .Action*  from 
Phase  1  Design 

1 

Receipt  of  external  tactical 
message  from  BOG/Corps 
(Event  No.  101) 

33 

2 

Receipt  of  retransmitted 
copy  of  another  section 
input  (Event  No.  102) 

78 

3 

Receipt  of  action  copy,  info 
copy,  query  answer,  and  any 
response  except  a  concurring 
chops  response  (Event  Nos. 

103,  106,  108,  110,  or  111) 

192 

4 

Internally  initiated  (INITIATE 
BY  SELF) 

15 

5 

Receipt  of  directive  from 
Conmander  or  concurring  chops 
response  (Event  Nos.  107  or 
109) 

20 

6 

Initiated  by  clock/SOP  (Event 
No.  ICO) 

6 

7 

Receiot  of  staff  query  or 
request  for  chops  (Event  Nos. 
104  or  10$) 

76 

TOTAL 


420 
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FIGURE  3-2.  CATEGORY  1  ACTIONS 

t-int  of  External  Tactical  Messages  front  BOG/CORPS 


the  populated  modules.  In  the  latter  case  the  individual  events  are 
to  be  interpreted  as  individual  procedural  steps,  i.e.,  elementary 
operations  ordinarily  performed  by  one  member  of  the  player  team. 

Figure  3-2  shows  that  Category  1  actions  always  culminate 
in  a  box  labeled  FORMAL  STAFF  ACTION.  This  box  denotes  a  continued 
sequence  of  staff  processing  events  whose  thread  chart  is  shown  in 
Figure  3-3.  The  formal  staff  action  segment  is  shown  in  a  separate 
chart  because  it  is  common  to  several  other  staff  procedure 
categories. 


Formal  staff  action  involves  a  number  of  elementary 
operations  with  Process/Skill  Levels  V,  and  VI.  The  segment  can  be 
thought  of  as  the  culminating  staff  processing  that  focuses  on  the 
tactical  decision-making  required  of  the  staff  element.  In  contrast 
to  this,  it  should  be  noted  from  Figure  3-2  that  the  front  half  of 
Category  1  actions  consist  almost  entirely  cf  lower  level  operations 
associated  with  the  maintenance  and  update  of  the  section  files  and 
displays.  The  single  exception  is  the  procedural  decision  choice 
EVALUATE  IN  CONTEXT  in  which  the  senior  staff  officer  determines 
whether  formal  staff  action  is  required  at  this  point  in  time. 

3.2. 1.2  Category  2  Actions 

The  second  category  of  staff  procedures  covers  all  actions 
triggered  by  receipt  of  retransmi tted  copies  of  another  staff 
element’s  input.  The  retransmission  copies  will  always  stem  from  the 
front  end  processing  of  Category  1  actions  by  another  staff  section. 
The  Category  2  event  thread  chart  is  shown  in  Figure  3-4. 

The  front  end  processing  of  Category  2  actions  clearly 
shows  a  different  structure  from  that  of  the  previous  category. 
Special  mention  should  be  made,  moreover,  of  the  sequence  of  events 
stemming  from  the  procedural  decision  choice  EVALUATE  IN  CONTEXT  shown 
in  the  cha  The  added  logical  structure  is  included  in  order  to 
accommodate  one  tactical  information  message  among  all  those  specified 
in  the  Phase  l  design.  This  message  is  the  Post-Strike  Analysis 
Report.  Formal  damage  analysis  is  performed  by  the  Fire  Support 
Element  following  a  strike,  but  the  FSE  is  supplied  with  the  raw  data 
for  his  analysis  through  the  receipt  of  retransmitted  copies  of 
Post-Strike  Damage  Reports  sent  to  G2.  Consequently,  whenever  FSE 
receives  a  (retransmitted)  Post-Strike  Damage  Report,  he  must  decide 
(in  EVALUATE  IN  CONTEXT)  whether  the  indivdual  report  provides  the 
trigger  criteria  to  begin  the  formal  analysis.  Furthermore,  after  he 
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has  embarked  on  the  formal  analysis ,  he  may  perceive  that  the  results 
of  the  analysis  not  only  must  be  sent  to  CG,  G2  and  G3,  but  also 
provide  the  basis  for  formal  staff  action  with  respect  to  the  division 
artillery  units.  The  added  logical  structure  here  in  the  Category  2 
event  thread  chart  is  devoted  solely  to  these  processing  requirements 
of  the  Post-Strike  Analysis  Report. 

3.2. 1.3  Category  3  Actions 

The  third  category  of  stiff  procedures  covers  the  largest 
group  of  actions  identified  in  the  Phase  1  design  (see  Table  3-4). 
The  actions  are  those  triggered  by  receipt  of  action  copies, 
information  copies,  staff  query  responses,  or  responses  to  all 
requests  except  concurring  chops  responses.  Category  3  actions  cover 
the  majority  of  staff  coordination  processes  in  the  battle  simulation. 
The  event  thread  chart  is  shown  in  Figure  3-5. 

The  front  end  processing  of  Category  3  actions  is  somewhat 
simpler  than  that  in  the  previous  categories.  Furthermore,  it  is 
anticipated  that  the  frequency  with  which  these  actions  will  terminate 
in  EVALUATE  IN  CONTEXT  (hence,  not  continue  on  into  formal  staff 
action)  will  be  higher  than  for  Categories  1  and  2.  The  vast  majority 
of  these  actions  will  simply  be  “paper  mill"  processing  in  which  the 
staff  section  receives  information  copies  of  another  section's  output 
and  no  further  disposition  is  indicated  beyond  the  filing  of  the 
subject  report. 

3. 2. 1.4  Category  4  Actions 

The  fourth  category  of  staff  procedures  cover  those  actions 
that  are  initiated  by  the  senior  staff  officer  because  he  holds  a 
perception  of  the  situation  or  problem  in  his  mind  and  has  determined 
that  formal  staff  action  should  be  instituted  forthwith.  The  event 
thread  chart  Is  shown  in  Figure  3-6. 

The  interpretation  o'  Category  4  staff  procedures  is  clear 
enough  for  live  staff  modules.  During  the  course  of  a  division-level 
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FIGURE  3-6.  CATEGORY  4  ACTIONS 
Internally  Initiated  Actions 


combat,  the  Commander  or  any  of  his  principal  staff  officers  may 
spontaneously  initiate  formal  staff  action  pertinent  to  the  successful 
execution  of  the  division's  assigned  mission.  However,  the  computer 
simulation  of  Internally  Initiated  actions  will  necessarily  fall  short 
of  modeling  the  human  brain  “when  the  light  comes  on."  As  stated  in 

paragraph  3.1.2,  the  elementary  operation  INITIATE  BY  SELF  has  no 

corresponding  Class  1  event  definition.  Class  1  events,  as  staff 
processing  steps,  were  originally  thought  to  be  task  performance  steps 

carried  out  by  a  simulated  staff  person  in  response  to  some  kind  of 

external  stimulus.  In  this  case,  "when  the  light  comes  on,"  the 
stimulus  is  Internal.  The  Phase  1  concepts  of  Class  1  events  and 
special  "release"  events  (Intervention  by  the  control  1 er( s) )  do  not, 
by  themselves,  provide  sufficient  framework  for  simulating  internally 
initated  actions.  The  actions  will  have  to  be  simulated  by 
programming  them  as  externally  triggered  events. 

The  additional  logical  framework  required  for  simulating 
Category  4  actions  is  presented  in  Section  4.  There  may  very  well  be 
behavioral  research  experiments  in  which  the  simulated  staff  modules 
will  be  triggered  to  reflect  Internally  initiated  actions  as  part  of 
the  dynamic  setting  that  is  presented  to  the  live  player  team. 

3.2. 1.5  Category  5  Actions 

The  fifth  category  of  staff  procedures  covers  those  actions 
triggered  by  receipt  of  a  directive  from  the  Commander  or  a  concurring 
chops  response.  The  actions  involve  only  a  small  number  of 
output-processing  tasks  since  the  basic  decisions  on  which  their 
output  frag  orders  or  Corps  requests  are  based  will  have  been  made  in 
other,  earlier  staff  actions.  The  event  thread  chart  is  shown  in 
Figure  3-7. 


For  the  processing  of  concurring  chops  responses,  Category 
5  staff  procedures  employ  the  decision-making  step:  COORDINATION 
COMPLETE?  The  procedural  rule  established  by  this  elementary 
operation  is  that  no  frag  order  or  Corps  request  for  which  chops 
requests  have  been  sent  out  shall  be  released  until  concurring 
responses  have  been  received  from  all  sections  solicited.  If  one  or 
more  chops  requests  are  returned  as  non-concurring  (and  consequently 
processed  as  Category  3  actions),  then  it  should  be  clear  that  the 
Category  5  processing  of  the  concurring  responses  will  terminate  at 
the  procedural  choice:  COORDINATION  COMPLETE?  and  not  culminate  in 
the  Issuance  of  a  frag  order  or  Corps  request. 


responses  been 
sections  solicited? 


FIGURE  3-7.  CATEGORY  5  ACTIONS 

Triggered  by  Receipt  of  a  Directive  from  the  Commander  or  a  Concurring  Chops  Response 


It  should  be  added  that  this  feature  of  the  Category  3  and 
Category  5  procedures  provides  the  senior  staff  officer  with  several 
recourses  If  a  proposed  course  of  action  "bounces"  with  one  or  more 
non-concurrences.  Under  the  Category  3  procedures,  he  may  reformulate 
the  proposed  course  of  action  taking  Into  account  the  objections 
raised  by  the  other  staff  officers,  or  he  may  resubmit  the  original 
output  but  this  time  route  It  for  the  Commander's  approval, 
notwithstanding  the  non-concurrences  from  the  other  sections. 

3.2. 1.6  Category  6  Actions 

The  sixth  category  of  staff  procedures  pertains  to  the 
periodic  reports  to  higher  headquarters  that  must  be  prepared  by  the 
division  staff.  These  actions  are  always  triggered  by  the  clock.  At 
the  appropriate  time  In  advance  of  the  due  time,  the  staff  section 
must  embark  on  the  report  preparation  tasks.  The  event  thread  chart 
is  shown  in  Figure  3-8. 

Category  6  procedures  are  applicable  to  the  following  six 
reports  identified  in  the  Phase  1  design: 

«  Division  Situation  Report,  prepared  by  G3 

t  Division  Intelligence  Summary,  prepared  by 
G2 

t  Intelligence  Paragraph  of  the  Division 
SITREP,  prepared  by  G2 

t  Preplanned  Request  For  Fire  Support, 
prepared  by  FSE 

t  Division  Personnel  Daily  Summary,  prepared 
by  G1/G4 

t  Division  Logistics  Report,  prepared  by  G1/G4 


It  can  be  seen  in  the  figure  that  the  first  step  in 
Category  G  procedures  is  the  operation  SYNTHESIZE  DATA  in  which  the 
senior  staff  officer  assembles  the  tactical  information  necessary  for 
the  composition  of  the  report.  The  data  are  compiled  from  the  section 
files/displays.  In  accordance  with  the  definition  of  this  elementary 
operation  (Table  3-2),  if  the  required  information  is  found  to  be 
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incomplete,  the  subsequent  processing  of  the  report  preparation  must 
be  switched  in  the  same  manner  as  that  shown  in  the  formal  staff 
action  segnent  (Figure  3-3).  For  example,  if  the  u3  finds,  In 
preparing  the  Division  SITREP,  that  the  G2  has  failed  to  submit  the 
Intelligence  Paragraph,  then  he  (the  G3)  cannot  proceed  with  his 
analysis  and  report  composition  but  instead  must  first  send  off  a 
staff  query  to  G2.  This  type  of  "contingent  procedural  switching" 
will  be  shown  to  be  a  significant  aspect  of  aberrant  human  performance 
in  Section  4. 

3. 2. 1.7  Category  7  Actions 

The  last  category  of  staff  procedures  covers  the  staff 
actions  attendant  upon  receipt  of  a  query  from  another  section  or  a 
request  for  concurrence  on  a  proposed  course  of  action.  The  event 
thread  chart  is  shown  in  Figure  3-9. 

In  the  staff  processing  of  queries,  the  Category  7 
procedures  exhibit  another  example  of  contingent  procedural  switching 
as  discussed  above.  According  to  the  Phase  1  design,  staff  queries 
are  limited  to  requests  for  the  latest  version  of  certain  Class  3  or 
Class  4  reports,  copies  of  which  are  kept  on  file  in  the  section 
having  cognizance  for  the  type  report.  The  G2,  for  example,  will  keep 
on  file  the  latest  copies  of  the  Wx  Forecast,  Bde  Intsums,  Estimate  of 
Enemy  Strength,  Composite  Target  List  (Intel),  Olvislon  Intsum,  and 
the  Intel  Paragraph  of  the  Division  SITREP  that  he  has  received  or 
generated.  At  any  time  he  may  receive  a  staff  query  from  another 
staff  section.  The  query  will  specify  one  of  these  reports,  and  in 
order  to  respond  to  the  query,  the  G2  must  withdraw  the  appropriate 
copy  from  his  files  (RETRIEVE)  and  send  It  off  to  the  section  who 
submi  tted  the  query. 

Now,  in  the  framework  of  the  example  described  above,  suppose 
the  G2  receives  a  query  from  G3  specifying  the  current  Intelligence 
Paragraph.  The  G3  submitted  the  query  because  he  had  found  (In  the 
Category  6  procedure)  that  he  could  not  compile  the  Olvislon  SITREP 
because  the  G2  had  failed  to  supply  the  Intelligence  Paragraph.  The 
G2  (now  in  the  Category  7  procedure)  would  discover  upon  attempting  to 
retrieve  the  aforesaid  report  from  his  files  that  the  material  was  not 
there  because  he  had  failed  to  generate  It  in  the  first  place.  As  a 
consequence  of  this  discovery,  the  G2  would  be  required  to  switch  away 
f’-om  the  normal  query  response  sequence  and  to  start  in  immediately  on 
the  compilation  and  composition  of  the  overdue  report.  This  second 
example  of  contingency  procedural  switching  suggests  even  more 
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FIGURE  3-9.  CATEGORY  7  ACTIONS 

pt  of  a  Staff  Query  or  a  Request  for  Concurrence 


strongly  the  significance  of  substandard  human  staff  performance  In 
behavioral  research  experiments. 

3.2.2  Preliminary  Discussion  of  Variable  Interface  Boundaries 

The  seven  event  thread  charts  presented  above  provide  the 
second  tier  of  building  blocks  with  which  the  logical  structuring  of 
simulated  modules  may  be  approached.  The  charts  also  provide  a 
visible  basis  for  addressing  the  second  design  requirement,  which  Is 
the  elimination  of  some  of  the  low-level,  repetitive  processing  tasks 
for  the  live  modules.  One  approach  to  this  requirement  Is  to  build  In 
the  capability  for  changing  the  Interface  boundaries  between  the  staff 
modules  and  the  rest  of  the  computer  simulation.  A  conceptual  picture 
of  these  boundaries  is  shown  In  Figure  3-10,  which  Is  taken  from  the 
Phase  1  design3.  The  annular  ring  In  the  figure  represents  the  five 
Blue  staff  modules.  The  unshaded  module  (G2)  Is  populated  with  human 
players;  the  remaining,  shaded  modules  are,  under  the  Illustrated 
configuration  of  play,  simulated  modules.  Within  this  annular  ring, 
the  staff  processing  of  the  tactical  information  will  be  governed  by 

the  staff  procedures  specified  by  the  seven  event  thread  charts.  The 

populated  module,  In  this  case  G2,  will  perform  Its  “play”  according 
to  the  action  SOPs  given  hy  the  charts.  The  simulated  modules  will 
represent  the  staff  processing  by  means  of  the  sequence  of  Class  1 

events  given  in  the  charts. 

In  this  framework,  the  input  interface,  which  is  denoted  by 
the  arrows  pointing  into  the  annular  ring,  corresponds  to  the  left 

hand  margins  of  each  of" the  seven  staff  processing  charts.  The  data 
transfer  into  the  staff  modules  is  always  followed  by  the  elementary 
operation  RECEIVE.  Similarly,  the  output  interface,  which  is  denoted 
by  the  arrows  coming  out  of  the  annular  ring,  corresponds  to  the 
implicit  data  transfer  following  the  elementary  operation  TRANSMIT. 
Although  there  are  several  isolated  occurrences  where  the  terminating 
TRANSMIT  operation  appears  in  the  middle  of  the  charts,  most  TRANSMIT 
events  appear  at  the  right  hand  margins. 


Tiede,  R.  V.,  Burt,  R.  A.  and  Bean,  T.  T.,  Design  of  an 
Integrated  Division-Level  Battle  Simulation  for  Research, 
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FIGURE  3- 


The  interface  boundaries,  specified  in  this  manner,  spell 
out  the  full  range  of  procedural  steps  or  Class  1  events  that  is 
required  in  the  staff  processing  by  a  division-level  staff.  The  steps 
include  all  the  low-level,  repetitive  information  processing  tasks 
that,  for  some  behavioral  research  investigations,  may  represent  so 
much  excess  baggage  in  terms  of  the  objectives  of  the  experiments. 

The  discussion  that  follows  introduces  the  idea  of  changing 
the  interface  boundaries.  In  order  to  show  the  implications  of  a 
relocated  boundary,  an  extreme  position  has  been  selected  for  the 
relocation.  The  selected  position  is  or-iented  to  a  live  staff  module 
consisting  of  only  one  player:  the  senior  staff  officer  and 
decision-maker.  If  the  battle  simulation  can  be  developed  so  that  it 
can  allow  the  play  of  one-man  live  staff  modules  based  on  this  extreme 
boundary  location,  then  other ,  intermediate  boundary  positions 
between  the  two  extremes  appear  entirely  feasible. 

The  proposed  boundary  for  a  one-man  pooulated  module  is  now 
illustrated  using  the  charts  for  Category  1  Actions.  Figures  3-11  and 
3-12  show  the  input  interface  and  the  output  interface  locations  if 
the  staff  processing  for  a  live  module  were  to  begin  at  the  point 
where  the  decision-maker  determines  whether  formal  staff  action  is 
required  at  this  time  (in  EVALUATE  IN  CONTEXT)  and  end  at  the  point 
where  he  effects  the  implementation  of  his  selected  cout.e  of  action 
(in  COMPOSE,  SELECT  ACTION,  or  COORDINATE  W.  STAFF).  The  data 
transfer  from  computer  to  player  or  from  the  player  back  to  the 
computer  would  take  place  at  these  points. 

Similar  interface  boundary  locations  can  be  generated  in 
the  remaining  event  thread  charts.  However,  it  can  be  seen  from  these 
figures  by  themselves  that  the  new,  extreme  positions  eliminate  nearly 
all  the  Level  I,  II,  III  and  IV  elementary  operations  from  the 
procedures  to  be  followed  by  the  one-man  live  staff  modules.  In  this 
conceptual  framework,  all  the  information  processing  at  the  beginning 
of  the  staff  action  and  all  output  processing  following  the  tactical 
decision  will  be  simulated  in  the  computer.  The  lone  player  in  the 
live  staff  module  must  address  only  the  fundamental  decision-making 
procedural  steps  which,  with  one  or  two  exceptions,  are  all  Level  V 
or  VI  operations. 

This  approach  to  providing  variable  interface  boundaries 
brings  out  the  central  design  problem  that  is  addressed  in  the 
companion  volume,  On  the  Design  of  Simulations  of  Command  and  Control 
Processes.  The  origina1  Phase  1  concept  included  the  Blue  perceived 
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data  base  as  the  primary  computer  storage  medium  for  the  body  of 
information  regarding  the  "state  of  the  battle"  held  by  the  Blue  side. 
The  transfer  of  data  from  the  perceived  data  base  to  the  live  players 
was  visualized  as  being  limited  to  about  seventy-five  standardized 
tactical  message  formats  whose  printing  or  cathode  ray  tube  display 
was  presented  one-at-a-time  to  the  players.  The  populated  modules,  in 
turn,  had  the  responsibl ity  for  maintaining  and  updating  their  own 
section  files,  status  boards,  and  situation  maps  so  that  the  tactical 
decisions  they  made  were  based,  among  other  things,  on  how  well  they 
organized,  aggregated,  and  sifted  their  own  data.  Now,  under  the  new 
boundary  location  described  above,  it  is  clear  that  the  computer  will 
take  over  the  input  information  processing  tasks  heretofore  assigned 
to  the  players.  But  how  is  this  section  data  base  information  to  be 
presented  to  the  lone  decision-maker  when  he  embarks  on  the  elementary 
operations  EVALUATE  IN  CONTEXT  or  SYNTHESIZE  DATA?  Is  he  provided 
with  a  fully  automated  situation  map  display?  Can  he  access  any  of 
his  section  files  by  means  of  keyboard  queries?  With  either  the 
extreme  boundary  position  or  even  an  intermediate  location  closer  to 
the  boundaries  implied  by  left  and  right  hand  margins  of  the  charts, 
the  computer  assistance  aspects  of  the  Phase  1  design  will  have  to  be 
enlarged.  One  part  of  this  expanded  requirement,  the  question  of  the 
computer  storage  of  the  staff  files  and  displays,  is  addressed  in  the 
next  section.  The  remainder  of  the  questions,  such  as  the  added  data 
presentation  formats  and  the  software  switching,  is  developed  in 
considerable  detail  in  the  companion  volume. 

3.3  POINTS  OF  OCCURRENCE  OF  VARIANT  HUMAN  PERFORMANCE 

This  subsection  now  merges  the  human  performance  material 
developed  in  Section  2  with  the  staff  processing  structures  discussed 
earlier  in  this  section.  The  objective  here  is  to  determine  where,  in 
the  execution  of  the  staff  actions,  relevant  human  errors  are  likely 
to  occur.  The  points  of  occurrence  of  aberrant  performance  will 
provide,  with  respect  to  populated  staff  modules,  basic  guidelines  for 
the  instrumentation  of  the  player  team.  The  determination  will  also 
provide,  with  respect  to  simulated  staff  processing,  the  embryonic 
logical  framework  by  which  the  computer/controller( s)  may  accommodate 
two  different  aspects  of  human  error  phenomena:  first,  the  simulated 
processing  attendant  on  substandard  performance  coming  from  the  live 
player  team,  and  second,  the  injection  of  simulated  errors  in  order  to 
observe  the  compensating  responses,  if  any,  by  the  live  team. 

The  points  of  occurrence  of  human  errors  in  staff 
processing  that  are  derived  here  become  central  to  the  logical  design 
of  the  simulated  staff  modules  as  presented  in  Section  4. 


3,3.1 


Three  Classes  of  Human  Error 


In  Section  2  human  errors  in  staff  processing  were 
classified  according  to  their  elemental  effect  on  the  Information 
processes.  Three  such  classes  were  identified.  This  classification 
is  repeated  here  in  order  to  illuminate  the  basic  relationships  with 
the  procedural  steps  in  the  staff  actions: 


•  Data  Error: 


t  Procedure 
Error: 


t  Cognition 
Error: 


Introduction  of  erroneous  or 
misleading  data  into  the  staff 
section  files/displays. 

Delaying  the  completion  of  the 
staff  action  by  making  a  false 
start  or  an  error  in  performance  of 
an  elementary  operation. 

Making  the  wrong  tactical  decision 
because  of  false  or  incomplete 
perception  or  inadequate  selection 
cri teria . 


The  caveat  that  went  with  these  effects  should  also  be  repeated.  It 
should  be  clear  that  while  the  errors  may  be  observed  as  discrete 
occurrences  in  a  live  staff  module,  the  consequences  of  such 
occurrences,  stenming  from  the  cause-and-effect  relationships  among 
them,  are  difficult  to  predict.  A  staff  section,  for  example,  could 
issue  an  incorrect  frag  order  because  of  at  least  three  different 
manifestations  of  human  errors.  First  of  all,  because  of  one  or  more 
data  errors,  the  decision-maker  might  construct  an  erroneous 
perception  of  the  situation  or  problem  at  hand  and  end  up  with  an 
inappropriate  tactical  decision.  Second,  because  of  cumulative  delays 
from  procedural  errors,  the  decision-maker  might  come  forth  with  an 
invalid  decision  since  the  decision  was  based  on  a  situation  now  three 
to  six  hours  old.  Finally,  even  though  he  is  confronted  with  a  timely 
and  accurate  picture  of  the  situation,  the  decision-maker  himself 
might  fail,  as  a  result  of  cognition  errors,  to  generate  the  full 
spectrum  of  alternatives  or  to  develop  adequate  evaluation  criteria 
and  therefore  end  up  with  the  wrong  tactical  decision.  Beyond  these 
three  simple  sequences  there  are  undoubtedly  numerous  combinations  of 
the  three  error  classes  that  could  lead  to  a  wide  variety  of 
alternative  outcomes.  Indeed,  it  can  be  argued  that  an  ironic  ,scomedy 
of  errors”  in  command  and  control  is  possible  under  the 
classifications.  A  situation  could  exist  where  data  errors  lead  to  a 
wholly  erroneous  picture  of  the  tactical  problem.  Thereafter  the 


decision-maker  makes  a  number  of  cognition  errors  which  fortuitously 
compensate  for  the  wholly  erroneous  perception.  In  this  unlikely 
circumstance  the  staff  section  might  come  forth  with  the  correct 
tactical  response  derived  entirely  for  the  wrong  reasons. 

6  As  discussed  in  paragraph  2.4.4  of  the  Phase  1  design 
report0  not  all  of  these  error  classes  are  either  observable  or 
measureable  directly  in  the  information  stream.  Data  errors  and 
procedural  errors  can  be  observed,  hence  measured,  directly  because 
the  data  stream  and/or  data  base  contains  a  reference  standard. 
Cognition  errors,  on  the  other  hand,  involve  the  generation  of  new 
information  not  previously  contained  in  the  information  stream;  hence, 
their  effect  can  be  observed  only  indirectly,  i.e.,  in  the  outcome  of 
combat.  As  pointed  out  above,  data  errors  and  procedural  errors  can 
also  affect  combat  outcomes.  One  must,  therefore,  carefully  control 
the  non-cognition  errors  if  the  effects  of  cognition  errors  are  to  be 
isolated. 


3.3.2  Frequency  of  Occurrence 

The  points  of  occurrence  of  the  human  error  effects  are 
identified  with  respect  to  the  27  elementary  operations  in  Table  3-5. 

The  table  shows  the  elementary  operations  and/or  Class  1 
events  as  they  are  listed  in  Tables  3-2  and  3-3.  The  estimated 
relative  frequency  of  occurrence  of  the  three  error  effects  is  shown 
in  the  labeled  columns.  As  indicated  in  Section  2,  no  adequate  data 
were  found  in  the  literature  to  support  the  relative  frequencies.  The 
estimates  shown  are  based  on  three  broad  factors  that  influence  the 
likelihood  of  occurrence  and  that  will  be  used  in  the  computer  logic 
for  simulated  staff  modules.  The  factors  are  as  follows: 

•  The  nature  of  the  elementary  operation 
itself. 

•  The  redundancy  of  the  information  content  in 
the  sense  of  information  theory. 

•  The  stress  or  fatigue  experienced  by  the 
staff  person  at  the  time. 


6  Ibid. 
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TABLE  3-5 


ESTIMATED  RELATIVE  FREQUENCY  OF  OCCURRENCE  OF  ABERRANT 


Event  No. 

PERFORMANCE  EFFECTS  IN 

E.  0.  Descriptor 

THE  ELEMENTARY  OPERATIONS 

Data  Procedure  Cognition 

Error  Error  Error 

100 

INITIATE  BY  CLOCK 

2 

101-112 

RECEIVE  OR  ACCEPT 

3 

2 

121 

DERI 

1 

2 

122 

DER2 

1 

2 

123 

DIR1 

1 

2 

124 

DIR2 

1 

2 

125 

ENTER 

2 

2 

126 

FILE 

2 

127 

MAKE  COPIES 

1 

130 

COMPOSE 

2 

1 

131 

DECOMPOSE 

1 

1 

132 

DETERMINE  COGNIZANCE 

1 

1 

133 

POST  or  PLOT 

2 

2 

134 

RETRIEVE 

2 

140 

COORDINATE  W.  STAFF 

1 

2 

141 

COORDINATION  COMPLETE? 

2 

1 

150 

EVALUATE  IN  CONTEXT 

2 

1 

INITIATE  BY  SELF 

1 

1 

2 

151 

SYNTHESIZE  DATA 

2 

1 

2 

152 

EVALUATE  DATA 

1 

1 

2 

153 

CONSTRUCT  PATTERN 

1 

1 

2 

154 

EXTRAPOLATE  SITUATION 

1 

1 

2 

155 

GENERATE  ALTERNATIVES 

1 

1 

2 

163 

ESTABLISH  CRITERIA 

1 

1 

2 

164 

EVALUATE  ALTERNATIVES 

1 

1 

2 

165 

SELECT  ACTION 

1 

1 

1 

189-199 

TRANSMIT  or  DELIVER 

3 

2 

Blank  -  Never  occurs 

1  -  Occurs  with  relatively  low  frequency 

2  -  Occurs  with  relatively  medium  frequency 

3  -  Occurs  with  relatively  high  frequency 
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SECTION  4 


LOGICAL  DESIGN  FOR  SIMULATED  STAFF  PROCESSING 


4.0  INTRODUCTION 

This  section  presents  the  logical  design  framework  for  the 
simulated  staff  modules  in  the  battle  simulation.  The  section  focuses 
on  the  added  design  requirement  related  to  the  human  errors  that  are 
known  to  occur  in  the  command  and  control  of  division-level  forces  and 
whose  occurrences  and  effects  are  an  important  and  promising  area  for 
behavioral  research  applications.  The  requirement  may  be  stated  in 
terms  of  two  questions  about  the  way  the  simulated  staff  modules  will 
operate: 

•  If  the  players  in  live  staff  modules  make 
errors  in  the  course  of  executing  their 
staff  functions,  can  the  simulated  staff 
modules,  subject  to  the  control  by 
investigators/controll ers ,  be  made  to 
"adapt"  to  the  substandard  human 
performance  so  that  the  consequences  of 
the  errors  will  be  reflected  in  the 
battle  outcome? 

•  Can  the  simulated  staff  modules,  again 
subject  to  the  intervention  by  the 
i nvestigators-controll ers ,  be  made  to 
exhibit  errors  in  their  own  staff 
processing,  so  that  the  players  in  live 
staff  modules  may  be  tested  to  see  if 
they  attempt  to  correct  the  mistakes 
before  they  are  reflected  in  the  battle 
outcome? 

Both  questions  are  oriented  to  the  coordination  required  between 
principal  staff  sections  for  effective  conmand  and  control  of  the 
division.  If  the  battle  simulation  can  be  implemented  with  the 


4-1 


requisite  Input  control  parameters  and  controller's  Intervention 
techniques  to  provide  these  features,  then  the  model  will  open  the 
door  to  a  wide  variety  of  behavioral  experiments. 

The  discussion  on  simulated  staff  processing  begins  by 
tracing  the  tactical  information  flow  in  the  model  as  a  whole,  as  it 
was  originally  conceived  in  the  Phase  1  design.  This  information  flow 
structure  is  then  refined  first  by  incorporati ng  the  details  of  the 
staff  procedures  from  Section  3  and  second  by  showing  where  human 
errors  are  involved  in  the  Tow  cycle.  The  refined  structural 
framework  is  then  used  as  the  basis  for  describing  the  logical  design 
of  Class  1  events  whose  structured  sequences  make  up  the  simulated 
staff  processing  in  the  model.  The  design  features  related  to  input 
control  parameters  and  to  controller's  release  events— the  mechanisms 
required  for  the  questions  cited  above-are  then  explored.  The 
section  is  concluded  by  a  review  and  restatement  of  the  functions 
required  of  invest! gators/control  1 ers  in  organizing  and  running 
behavioral  research  experiments  with  the  enhanced  design  concept  for 
the  battle  simulation. 

4.1  TACTICAL  INFORMATION  FLOW  IN  THE  SIMULATION 

One  of  the  principal  features  of  the  Phase  1  design  concept 
is  the  explicit  treatment  of  the  flow  of  tactical  information  messages 
between  the  combat  units  engaged  with  the  opposing  forces  and  the 
division  Command  Group  and  its  chief  staff  sections.  Whenever  one  or 
more  of  the  Blue  staff  modules  are  manned  by  teams  of  human  players, 
the  tactical  information  flow  is  manifested  by  the  players  "receiving" 
messages  from  the  battlefield  and  their  "transmitting"  in  turn  new 
frag  orders  or  queries  back  to  the  subordinate  units.  The  treatment 
is  explicit  because  the  players  are  confronted  with  realistic  formats 
and  printed  content  based  on  about  seventy-five  selected  tactical 
message  formats. 

The  flow  of  tactical  information  in  the  model  is 
illustrated  in  Figure  4-1.  The  figure  shows  the  flow  cycle  as  it  was 
originally  conceived  in  the  Phase  1  design.  The  flow  of  information 
can  be  seen  to  circulate  through  three  different  conceptual  entities: 
the  real  world  data  base,  the  Blue  perceived  data  base,  and  the  Blue 
staff  modules.  A  similar  flow  cycle  exists  for  the  Red  side,  but  in 
keeping  with  the  fundamental  asymmetry  of  the  design  concept,  the  Red 
conmand  and  control  module  consists  only  of  the  Red  Conwander  by 
himsel f. 

The  flow  of  tactical  information  messages  is  governed  in 
the  simulation  by  the  occurrence  of  events.  The  ground-truth  facts 
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SIMPLIFIED  ILLUSTRATION  OF  THE  TACTICAL  INFORMATION  FLOW  IN  THE  BATTLE  SIMULATION 
ORIGINAL  PHASE  1  DESIGN 


about  the  on-going  battle  are  carried  from  the  real  world  data  base  to 
the  Blue  perceived  data  base  by  means  of  report-related  Class  5 
events.  These  events  cover  the  Intelligence  gathering  and  status 
reporting  activities  taking  place  In  the  BOG.  The  general  Blue 
perceptions  of  the  battle  are  then  carried  from  the  perceived  data 
base  to  the  cognizant  staff  module  by  means  of  the  Class  4  Interface 
events.  The  Interface  boundary  between  the  perceived  data  base  and 
the  staff  modules  Is  not  shown  In  the  figure,  but  It  Is  located  just 
to  the  right  of  the  perceived  data  base.  Upon  receipt  of  the  Class  4 
reports,  the  staff  modules  then  establish  the  flow  of  Input 
coordination  messages  by  means  of  the  Class  2  events.  The  description 
thus  far  covers  the  first  half  of  the  flow  cycle. 

The  second  part  of  the  cycle  begins  w'.th  the  staff 
processing  performed  by  the  staff  modules.  Acting  on  the  basis  of  the 
tactical  Information  It  receives,  each  module  performs  the  required 
command  and  control  functions  within  Its  purview  and  Issues  or 
transmits  frag  orders  or  queries  pertinent  to  the  successful  execution 
of  the  division’s  assigned  mission.  The  formulation  and  generation  of 
these  new  messages  Is  effected  by  Class  1  events.  The  transmission  of 
the  messages,  carrying  the  new  orders  or  queries  to  the  appropriate 
addressees  in  the  BCG,  Is  governed  by  means  of  the  Class  3  interface 
events.  Concomittant  with  the  start  outputs  are  the  output 
coordination  messages  (information  copies)  shown  by  the  second  bar  of 
Class  2  events.  The  Interface  boundary  between  the  staff  modules  and 
real  world  data  base  Is  also  not  shown,  but  It  lies  somewhere  along 
the  bar  at  the  bottom  of  the  figure.  This  “closes  the  loop"  for  the 
information  flow  cycle. 

Figure  4-1  highlights  the  fact  that  the  staff  processing 
internal  to  the  staff  modules  was  not  fully  defined  in  the  Phase  1 
design.  A  preliminary  discussion  of  the  concept  of  Class  1  events  was 
given  in  Design  Note  I,  but  the  list  of  defined  events  was  incomplete 
for  the  class  because  the  level  of  procedural  detail  to  be  used  had 
not  yet  been  determined. 

The  completion  of  the  list  of  defined  Class  1  events  and 
the  detailing  of  the  staff  procedures  from  the  previous  section  now 
permit  the  first  refinement  to  be  made  on  the  picture  of  the  tactical 
information  flow. 
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4.1.1  Staff  Processing  Details 

The  role  of  staff  processing  In  the  Information  flow  cycle 
can  be  Illustrated  by  grouping  the  procedural  steps  In  Action 
Categories  1,  2,  and  3  (Figures  3-2,  3-4,  and  3-5;  also  Figure  3-3) 
Into  three  basic  stages:  maintenance  and  update  of  the  section 
flles/dl splays,  generation  of  the  perception  and  decision-making,  and 
output  processing.  Upon  receipt  of  a  tactical  information  message,  a 
staff  section  usually  goes  through  these  three  stages  of  staff 
processing.  For  the  purposes  of  showing  a  refined  picture  of  the 
general  Information  flow,  the  subtle  variations  on  this  simplified 
framework  Implied  by  the  remaining  action  categories  can  be  Ignored 
for  the  moment.  Action  Categories  1,  2,  and  3  cover  the  majority  of 
the  staff  processing  requirements. 

The  first  refinement  to  the  Information  flow  diagram  Is 
shown  In  Figure  4-2.  The  figure  shows  that  the  staff  processing  In 
each  of  the  five  staff  modules  consists  of  the  same  three  basic 
stages.  While  the  specific  types  of  tactical  messages  it  receives  and 
the  specific  organization  of  Its  files/displays  both  depend  on  the 
area  of  functional  responslbl 1 ty  for  an  individual  module,  the  general 
pattern  of  information  flow  through  the  module  is  the  same  for  all 
staff  sections. 

At  this  point,  a  review  of  the  concept  behind  the  perceived 
data  base  is  pertinent.  In  the  Phase  1  design1,  the  Blue  and  Red 
perceived  data  bases  were  characterized  as  follows: 

“The  perceived  data  base  on  each  side  consists  of  the 
side*$  perception  of  its  own  troop  list  and  operations  SITHAP  as  well 
i:  the  enemy  order  of  battle  and  dispositions.  The  real  world  data 
base  and  the  separate  perceived  data  bases  are  conceived  as  distinct 
odies  of  information  because  neither  side  will  ever  enjoy  true  and 
j!1  knowledge  of  the  deployment  of  the  units  of  the  other  side  nor 
even  up-to-date  and  precise  knowledge  of  its  own  troops.  Accordingly, 
the  basic  design  concept  includes  a  Blue  and  Red  perceived  data  base 
each  containing  unaggregated  information  about  Its  own  troops  and  the 
enemy  forces.  During  the  course  of  tne  play,  the  Information  in  these 
data  bases  will  be  continually  modified  by  the  occurrences  of  the 
Class  5  report  generation  events.  The  occurrences  will  usually  be 

followed  by  corresponding  Class  4  events  at  which  times  the  staff 
modules  will  receive  tactical  information  messages.  The  messages  will 
be  formatted  according  to  standard  message  formats  and  based  on  data 
aggregated  from  the  perceived  data  base.  Thus,  the  state  of  battle 


I  Tiede,  R.  Y.,  Burt,  R.  A.,  and  Bean,  T.  T.,  Design  of 
an  Integrated  pi  vision-levs!  Battle  Simulation  fcr 
Research,  Development,  and  Tra 1 ni n a" (Army  ftesearc h 
Institute  Draft  Technical  Report,  August  1979). 
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reflected  in  the  information  will  always  be  delayed  in  time  and 
subject  to  errors  and  omissions  with  respect  to  the  true  facts  in  the 
real  world  data  base. 

"In  concept,  the  perceived  data  base  will  always  exist  in 
two  forms:  first  as  tabular  arrays  of  data  available  ordinarily  only 
to  the  controller! s)  and/or  computer,  and  second  as  the  series  of 
troop  lists,  modified  organizations  for  combat,  situation  map 
overlays,  numerous  files,  etc.,  set  up  and  maintained  by  human  players 
in  populated  staff  modules  during  an  exercise.  The  first  form  may  be 
thought  of  as  the  body  of  facts  about  the  conflict  marshalled  by  the 
Blue  or  Red  sides,  while  the  second  form  will  reflect  the  way  the 
commander  and  his  staff  organize,  aggregate,  and  sift  the  known  facts 
to  facilitate  decision  making." 

Now  the  "first  form”  of  the  biue  perceived  data  base  is 
simply  the  labeled  box  shown  in  Figures  4-1  or  4-2.  But  the  "second 
form",  at  least  with  respect  to  populated  staff  modules,  is  the  small 
box  shown  as  the  "section  files/displays"  for  an  individual  module. 

The  section  files/ displays  box  is  hereafter  called  the  section  data 
base  because  it  represents  the  body  of  information  from  which  the 
decision-maker  generates  his  perception  of  a  problem  and  on  which  he 
bases  his  tactical  decision.  The  validity  of  the  so  fion  data  base, 
that  is,  the  degree  to  which  the  second  form  corresponds  to  the  first 
form  of  the  perceived  data  base,  is  clearly  a  function  of  how  well  the 
tactical  information  from  successive  messages  is  incorporated  into  the 
section  data  base. 

One  could  summarize  the  distinction  between  the  data  bases 

as  follows: 

•  Real  World  Data  Base  -  information  about 
what  really  happens  in  the  division-level 
confl  ict. 

9  Perceived  Data  Base  -  sum  total  of 
knowledge  one  side  holds  about  the 
conflict  potentially  available  to 
decision  makers  of  one  side;  this 


2  Ibid, 

3  Ibid. 
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information  is  generated  by  the 
intelligence  gathering  and  status 
reporting  functions  employed  by  the  side. 

•  Section  Data  Base  -  information  taken 
from  the  perceived  data  base  but 
reorganized  and  sifted  according  to  the 
area  of  functional  responsibility  of  the 
staff  section.  This  is  the  information 
actually  available  to  the  decision 
makers. 


Figure  4-2  brings  out  two  points  worthy  of  more  detailed 
discussion.  The  first  is  related  to  the  difference  between  manual 
staff  processing  and  processing  with  t  assistance,  as  seen  from  the 
perspective  of  the  general  tactical  information  flow.  The  second  is 
concerned  more  concretely  with  the  implementation  of  simulated  staff 
processing  in  a  computer.  The  separate  issues  are  discussed  below. 

4.1. 1.1  AD?  -  Assisted  Staff  Processing 

The  general  design  concept  in  the  Phase  1  report  contained 
provisions  for  exercising  the  staff  modules  not  only  under  a  manual 
staff  system  but  also  under  a  staff  system  provided  with  ADP 
assistance.  The  design  considerations  directed  toward  the  latter  mode 
of  operation  included  the  following: 


•  Requirement  for  an  added  sixth  class  of 
events  and  for  the  specification  of  the 
alternative  tactical  information  displays 
associated  with  these  Class  6  events. 

•  Requirement  for  additional  hardware  to 
provide  a  realistic  environment  for  the 
players  in  a  populated  staff  module* 

•  Software  techniques  for  asynchronous  data 
entry  from  several  different  player's 
terminals. 

•  Software  additions  for  emulating  the 
computerized  decision-making  aids  built 
into  the  field  ADP  facilities. 
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Although  these  Items  were  fully  identified  in  the  basic  design,  It  was 
recommended  that  the  initial  implementation  of  the  model  proceed 
without  them  because  the  terminal  hardware  specifications  and  the 
software  emulation  routines  were  not  fully  defined  at  the  time. 

The  conceptual  picture  of  tactical  information  flow  (Figure 
4-2)  nevertheless  now  provides  an  interesting  perspective  for 
comparing  a  manual  staff  system  with  ADP-assIsted  staff  processing. 
The  obvious  disadvantage  of  a  manual  system  as  well  as  Its  more  subtle 
shortcomings  can  be  revealed  by  tracing  the  information  flow  through 
the  staff  processing  boxes.  The  diagram  can  also  be  used  to  identify 
the  fundamental  tactical  data  management  objectives  for  a  field  ADP 
system. 


The  principal  difficulty  with  a  manual  staff  system  lies  In 
the  first  stage  of  action  processing  shown  in  the  figure.  Maintenance 
and  update  of  the  section  data  base  attendant  on  the  receipt  of  a 
tactical  message  are  performed  entirely  by  hand  by  subordinate  members 
of  the  staff  section.  Management  and  processing  of  the  vital  tactical 
data  are  handled  by  means  of  complicated  staff  procedures  consisting 
of  a  large  number  of  elementary,  and  sometimes  trivial,  operations. 
Since  the  categories  of  staff  actions  in  Section  3  are  oriented  to  a 
manual  staff  system,  the  complexity  and  time-consuming  aspect  of  the 
input  information-processing  can  be  seen  by  looking  at  the  front  end 
of  the  event  thread  charts  (e.g.,  Figures  3-2,  3-4,  and  3-5), 


The  amount  of  time  taken  for  information-processing  before 
the  senior  staff  officer  can  begin  to  formulate  his  perception  of  the 
situation  can  often  spell  the  difference  between  effective  or 
inadequate  command  and  control,  even  if  the  successive  tactical 
messages  were  to  come  in  at  reasonably  spaced  time  intervals.  The 
time  delays  are  predictably  much  worse,  however,  whenever  the  staff 
element  experiences  a  "busy  hour"  when  the  tactical  messages  are 
coming  in  simultaneously  on  several  diffejent  communications  channels, 
one  after  another.  An  earlier  study  has  shown  that  the  time 
necessary  to  complete  the  input  processing  or  the  entire  staff  action 


4  Tiede,  R.  Y.,  Walker,  M.  E.,  Stenstrom.  0.  J.,  and 

Sweeny,  S.  0.,  The  Integrated  Battlefield  Control  System 
(IRCS)  Third  Refinement  Study  (McLean,  Va.:  Science 
AppTfc  a t i ons ,  1  nc . ,  HnaT  Report,  March  1975) 
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can  be  lengthened  as  much  as  100%  or  more  simply  because  the  ’.4  or  E7 
performing  the  initial  input  operations  has  an  inordinate  number  of 
tasks  piled  up  in  his  in-basket. 

A  second,  more  obscure  problem  with  manual  systems  can  be 
demonstrated  by  referring  again  to  Figure  4-2.  The  basic  idea  behind 
the  perceived  data  base  and  the  individual  section  data  bases  Is  that 
each  section  data  base  represents  a  recasting  of  the  "state  of  the 
battle"  information  from  the  perceived  data  base  according  to  the 
section1 s  area  of  functional  responsibility.  This  means  that  the  five 
staff  sections  are,  in  principle,  looking  at  the  same  picture  of  the 
conflict  but  are  extracting  nuances  (i.e.,  tactical  data)  from  the 
picture  that  are  relevant  to  their  separate  areas  of  responsibility. 
This  is  fine  just  so  long  as  the  coordination  between  the  staff 
sections  is  sufficient  to  assure  that  they  continue  to  look  at  the 
same  overall  picture.  Staff  coordination  in  fact  serves  two  basic 
purposes.  First  it  is  a  mechanism  for  detecting  and  correcting  gross 
errors.  Secondly  it  serves  to  keep  the  separate  section  data  bases 
reasonably  well  coordinated. 

In  a  manual  system,  the  staff  coordination  procedures  are 
executed  entirely  by  staff  personnel.  A  breakdown  or  failure  of  staff 
coordination  due  improper  procedures  or  to  human  errors  will 
inevitably  lead  to  section  data  bases  that  are  no  longer  based 
uniformly  on  the  same  picture  of  the  war.  In  short,  in  a  manual 
system,  when  the  five  cooks  attempt  to  taste  the  soup  from  the  same 
pot  on  the  stove,  human  errors  will  serve  to  sprinkle  more  salt  or 
sugar  into  the  soup  spoon  as  it  passed  among  them. 

These  shortcomings  within  a  manual  staff  system  immediately 
suggest  the  direction  and  thrust  that  one  would  expect  to  be  taken  in 
the  development  of  ADP  facilities  to  assist  in  the  concentration  of 
forces  by  a  division  commander.  An  AOP  system  should  be  overlaid  on 
division  structure  to  provide  basic  automated  processing  capability 
down  to  the  desired  echelon.  Furthermore,  the  system  should  be 
designed  to  provide  the  capability  to  exchange  data  both  internal  and 
external  to  the  division,  to  build  and  maintain  data  files,  to  perform 
analysis  support,  and  to  provide  a  graphic  display  capability  to 
support  division  operations. 

Implicit  in  these  requirements  is  the  recognition  that  each 
of  the  subordinate  units  on  the  battlefield  "sees"  different  aspects 
of  the  perceived  data  base  Indicated  in  Figure  4-2.  There  is  a 
natural  tendency  for  knowledge  among  and  between  staffs  (derived  from 
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the  perceived  data  base)  to  diverge  if  there  is  not  a  conscious  effort 
to  institute  and  execute  staff  coordination  procedures.  Even  with 
excellent  vertical  and  lateral  staff  coordination  the  knowledge  on  the 
part  of  each  unit  will  tend  to  diverge  due  to  time  delays,  human 
errors  and  the  orientation  of  each  unit.  Accordingly,  it  has  been 
seen  as  a  significant  problem  area  on  today's  dynamic  battlefield  and 
AOP  systems  should  provide  the  battlefield  with  a  common  data  base, 
accessible  by  all  units.  This  concept  would  provide  all  commanders 
with  the  required  level  and  detail  of  information  which  would  lead  to 
more  timely  analysis  of  the  dynamic  battlefield  and  reduce  the 
uncertainty  in  decision  making. 

There  is  also  a  requirement  for  section  data  base  within 
each  unit's  staff.  This  feature  must  provide  each  staff  section  the 
capability  to  extract  information  that  it  needs  in  order  to  execute 
its  function  on  a  continual  basis.  As  each  staff  Inputs  new 
information  or  modifies  existing  information  the  common  data  base  is 
essentially  updated  for  all  other  users.  This  concept  reduces 
information  processing  times,  decreases  the  possibility  of  compounding 
human  error  and  Increases  the  effectiveness  of  staff  coordination  at 
all  levels. 


It  is  clear  then  that  a  battlefield  AOP  system,  if 
implemented  properly,  can  alleviate  most  of  the  problems  associated 
with  the  vertical  and  lateral  transfers  of  information  among  all 
division  units.  However,  it  Is  conjectured  that  the  ADP  system  should 
not  only  alleviate  information  processing  problems  but  it  should  also 
provide  an  additional  bridge  between  the  information  and  the  ultimate 
decision  made  by  staffs.  That  Is,  decision-aiding  techniques  could, 
among  others  be  applied  to  enemy  activity  and  movement,  enemy  order  of 
battle,  logistical  considerations,  and  the  most  likely  outcome  of 
alternative  courses  of  action. 

The  Phase  1  design  addressed  and  resolved  many  of  the 
issues  brought  out  above.  For  example,  the  simulation  has  been 
designed  as  a  storage  and  retrieval  system  for  Incoming  and  outgoing 
messages  as  they  pertain  to  the  division  staff.  All  of  the  various 
staff  modules,  whether  populated  or  simulated  had  access  to  a  common 
"perceived"  data  base.  The  design  of  this  perceived  data  base  was 
modeled  upon  the  automatic  receipt  and  distribution  of  incoming 
messages  based  on  specific  message  characteristics.  To  design  the 
common  perceived  data  base,  reporting  requirements  of  the  division 
were  ascertained  and  the  data  utilization  at  the  division-level  was 
assimilated  into  the  information  flow  of  specific  staff  modules. 
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This  design  concept  had  the  advantage  of  allowing  populated 
staff  modules  to  structure  their  own  section  data  base  from  incoming 
tactical  messages  and  queries  made  to  the  common  perceived  data  base. 
Players,  however,  would  not  directly  interact  with  the  computer.  This 
design  met  the  Phase  1  design  objectives  in  that  It  closely 
approximated  the  existing  manual  system  and  would  therefore  allow 
experimental  psychologists  to  examine  human  behavior  within  the 
desired  environment.  The  introduction  of  the  Phase  2  requirements  for 
modeling  variant  human  behavior  and  for  reducing  the  populated  modular 
boundaries  has  forced  the  examination  of  the  design  from  a  TOS-like 
perspective.  Specification  of  automatic  routing  of  transmitted  as 
well  as  received  messages  within  simulated  staff  modules,  as  defined 
in  the  staff  action  categories  of  Section  3,  will  now  permit  the 
reduction  of  the  boundaries  around  a  populated  module  and  thus 

increase  the  economy  of  operations3.  Under  such  a  mode,  the  players 
will  now  be  directly  involved  with  the  computer. 

This  idea  has  grown  out  of  the  Phase  2  requirements  and  has 
provided  significant  Insight  on  how  to  achieve  the  objectives  of  an 

ADP  assisted  command  and  control  system.  It  leads  to  the  following 

concl usions: 

•  That  a  common  data  base  does  not,  without 
special  processing,  provide  information 
in  a  structure  that  is  of  immediate 
utility  to  a  variety  of  users  such  as 
that  represented  by  a  division  staff. 

t  That  the  Information  contained  in  the 

common  data  base  should  be  manipulated  by 
the  computer  and  displayed  to  the 
functional  user  in  a  manner  that  Is  of 
immediate  utility  to  him. 


5  Although  this  boundary  reduction  is  technically  feasible,  the 
credibility  and  realism  of  the  simulation  may  suffer.  This' 
trade-off  is  addressed  further  in  the  companion  report. 


4-12 


The  "files/display"  boxes  of  Figure  4-2  are  a  representation  of  this 
design  philosophy  and  as  such  the  design  will  facilitate  the 
simulation  of  an  AOP  assisted  command  and  control  system.  The  design 
and  design  alternatives  presented  throughout  the  remainder  of  this 
report  will  adhere  to  this  section  data  base  concept. 

4. 1.1.2  Computer  Implementation  of  Simulated  Staff  Processing 

A  large  part  of  the  Phase  1  report  was  directed  at  the 
cost-benefit  trade-offs  that  were  implied  if  computer  assistance  were 
used  to  implement  different  elements  of  the  basic  design.  The 
discussion  began  by  considering  the  size  and  organization  of  the  total 
body  of  data  on  which  the  exercise  of  the  battle  simulation  would  be 
based.  It  was  then  shown,  on  the  basis  of  these  data  structure 
requirements,  that  an  effective  tool  for  research,  development,  and 
training  could  be  developed  using  the  computer  (1)  to  set  up  the 
exercise  and  (2)  to  assist  in  the  timing  and  the  pursuit  of  the 
research  objectives  while  the  exercise  was  running.  The  first  of 
these  functions  was  embodied  in  a  three-stage  preprocessing  system 
which  lead  to  a  SCENARIO  File.  The  second  function  was  handled  oy  an 
interactive  executive  control  routine  (IECR)  which  read  the  SCENARIO 
File  and  then  embarked  on  the  dynamic  portrayal  of  the  combat 
situation.  The  two  software  packages,  as  well  as  the  file  that 
bridged  between  them,  were  based  on  the  common  data  structure 
conceived  for  the  overall  system. 


The  five  major  data  groups  contained  in  the  required  data 
structure  were  as  follows: 

•  Real  World  Data  Base 

•  Blue  Perceived  Data  Base 

•  Red  Perceived  Data  Base 

•  Event  Table 

t  Message  Format  Specifications  and  Data  Element 
Dictionary 

These  data  groups  were  estimated  to  take  up  316,000  bytes  of  data 
space  in  the  computer.  The  data  space  requirements,  along  with  the 
instruction  space  requi rements,  provided  the  basis  for  formulating  the 
cost-benefit  judgements. 
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It  should  now  be  clear  that  the  Phase  1  data  structure 
omitted  the  data  space  requirements  for  the  section  data  bases.  Prior 
to  this  Phase  2  study,  it  was  tacitly  assumed  not  only  that  the 
simulated  staff  modules  would  operate  like  Idealized  division  staff 
elements  but  also  that  they  would,  where  required,  make  reference,  not 
to  their  own  section  pool  of  information,  but  to  the  unaggregated 
tactical  Information  In  the  perceived  data  base.  In  the  original 
concept,  section  data  bases  were  defined  as  the  section  flles/dl splays 
used  by  live  staff  modules  and  located  entirely  outside  the  computer. 

The  discussion  now  turns  to  the  question  of  computer-stored 
section  data  bases.  Should  the  basic  data  structures  of  the 
simulation  software  be  expanded  to  include  a  sixth  major  data  group 
covering  section  data  bases?  The  software  design  already  contains  two 
data  bases:  the  Real  World  Data  Base  and  the  Perceived  Data  Base.  It 
will  now  be  shown  that  the  Incorporation  of  a  third  data  base 
(consisting  of  five  separate  section  data  bases)  will  provide  a  more 
realistic  portrayal  of  the  tactical  information  flow  as  well  as  the 
simulated  staff  processing,  but  will  require  significantly  increased 
software  development  as  well  as  expanded  preprocessing  functions 
devolving  on  the  investigators/controllers.  The  division-level  battle 
simulation  can  be  built  without  the  third  data  base,  but  the  simulated 
information  flow  and  the  simulated  staff  activity  in  this  framework 
will  exhibit  subtle  discrepancies  in  the  tactical  information  messages 
and  tactical  data  displays  presented  to  the  live  players.  Because 
this  development/realism  trade-off  is  ARI's  prerogative,  the  logical 
design  material  presented  in  the  next  subsection  will  be  found  to  be 
approached  from  two  separate  points  of  view:  first  using  the  expanded 
data  structure  containing  the  third  data  base  and  then  using  the  more 
limited  framework  without  computer- stored  section  data  bases. 

The  principal  reason  the  third  data  base  will  Improve  the 
simulated  staff  pressing  and  the  information  flow  in  the  model  is 
that  it  will  represent  the  "state  of  the  battle"  information  held  at 
any  moment  by  the  division  staff.  If  the  model  is  exercised  assuming 
a  manual  staff  system,  the  body  of  Information  held  by  the  staff  will 
consist  of  five  separate  section  data  bases,  each  containing  tactical 
data  organized  and  filed  according  to  the  particular  functional 
requirements  of  the  staff  section.  If  the  model  is  exercised  assuming 
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an  ADP-assIsted  command  and  control  system,  the  same  body  of 
Information  will  represent  the  common  tactical  data  base  associated 
with  the  field  computer  system.  The  comnon  tactical  data  base  may  be 
partitioned  with  respect  to  the  separate  staff  section  functions  and 
will  always  be  accessed  and/or  updated  by  the  separate  sections 
according  to  the  rules  and  data  organization  specified  for  the  field 
ADP  system.  When  emulating  either  a  manual  mode  or  an  ADP-assisted 
mode,  however,  the  third  data  base  will  be  subject  to  changes  In  Its 
state  of  the  battle  information  only  through  discrete  occurrences  of 
Class  1  events  (staff  processing  operations)  or  Class  2  events  (staff 
coordination  exchanges).  Any  Individual  Item  of  tactical  data  In  the 
data  base  will  remain  at  Its  unmodified  value  or  setting  until  It  Is 
updated  or  changed  by  a  specific  action  performed  by  either  man  or 
machine  in  the  division  staff  system.  For  example,  If  the  G3  section 
files  the  latest  SITREP  received  from  the  first  brigade,  the  entire 
tactical  data  contents  of  the  report  will  remain  unchanged  In  the  data 
base  until  superseded  by  the  receipt  and  filing  of  the  next  SITREP 
from  the  same  brigade. 

In  contrast  to  this,  the  perceived  data  base  will  be 

changing  dynamically  throughout  the  simulated  combat.  With  each 
occurrence  of  the  Class  5  events  related  to  the  on-going  Intelligence 
gathering  and  status  reporting  activity  in  the  BOG,  Individual  data 
Items  in  this  data  base  will  change  continually  In  a  manner  almost 
entirely  indpendent  of  the  actions  taken  by  the  personnel  or  machines 
at  division  headquarters.  In  the  example  above,  the  tactical  data 
contents  of  the  Brigade  SITREP  sent  to  the  G3  will  correspond  to  the 
situation  data  in  the  perceived  data  base  only  for  the  moment  In  time 
at  which  the  Class  4  event  occurs.  Ten  minutes  later,  or  five  hours 
later,  the  same  situation  data  items  will  have  changed  in  the 

perceived  data  base  while  the  material  in  the  SITREP  on  file  with  the 
division  staff  will  remain  unchanged. 

This  property  of  the  third  data  base  is  important  in  the 

realistic  simulation  of  staff  processing  because  several  elementary 
staff  operations  (e-g. ,  RETRIEVE  and  SYNTHESIZE  DATA)  Involve  the 

accessing  of  tactical  data  already  on  file  in  the  data  base.  The 
added  data  base  can  emulate  either  the  section  files/displays  used  by 
a  manual  staff  system  or  the  common  tactical  data  base  contained  in  a 
field  computer  system.  The  "state  of  the  battle"  Information  held  in 
this  body  of  data  will  be  subject  only  to  the  manipulations  stemming 
from  staff  operations. 

There  are  other,  lesser  advantages  to  incorporating  the 
third  data  base.  Under  a  manual  mode  of  staff  operations,  one  of  the 
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basic  problems  was  shown  to  be  the  inevitaLle  divergence  that 
developed  between  different  section  files/displays  during  the  course 
of  combat  operations.  These  tactical  data  discrepancies  arise  because 
of  human  errors  that  occur  In  the  coordination  processes  between  staff 
sections.  By  using  suitable  software  data  organization,  the  third 
data  base  can  provide  a  means  to  measure  this  divergence  as  It 
develops  In  an  exercise  of  the  model. 

The  third  data  base  can  also  be  used  in  a  special  manner 
wherever  one  or  more  of  the  staff  modules  are  populated  as  staff 
sections  under  a  manual  system.  The  actual  section  data  bases  of 
these  teams  will  consist  of  the  filing  cabinets,  display  boards,  and 
situation  maps  the  players  will  use  and  maintain  during  the  exercise. 
The  software  section  data  bases,  which  would  ordinarily  not  be 
Involved  In  the  play,  could  In  fact  be  maintained  in  parallel  by  the 
computer  and  provide  thereby  a  comparison  standard  for  the  real 
section  files/displays  outside  the  machine.  With  a  live  G3  module, 
for  example,  the  Front  Line  Trace  could  be  compared  at  the  end  of  the 
run  against  a  printout  from  the  third  data  base. 

Under  an  ADP-assIsted  staff  system,  the  third  data  base 
will  facilitate  the  generation  and  formatting  of  the  alternative 
tactical  data  displays  used  by  live  staff  modules.  It  will  also 
facilitate  the  use,  by  either  populated  modules  or  simulated  modules, 
of  alternative  sets  of  access  and  update  rules  that  might  be  specified 
for  the  automated  command  and  control  system.  These  Implications  of 
the  added  data  structure  are  developed  further  in  Section  5. 

The  cost  of  third  data  base,  in  terms  of  the  added  software 
development  and  the  extended  preprocessing  functions,  can  be 
summarized  as  follows: 

•  The  added  data  spa«.e  requirement  for 
the  sixth  major  data  group  is 
estimated  to  be  100,000  bytes.  This 
makes  the  overall  requirement 
416,000  bytes. 

t  The  software  data  organization  of 
the  new  data  base  will  have  to  be 
hardwired  in  the  computer  programs. 

For  manual  mode  applications,  the 
section  data  base  subdivisions  will 
have  to  be  tailored  to  *he  separate 
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areas  of  responsibility  of  the 
different  sections.  For 

ADP-assisted  mode  applications,  the 
rules  for  accessing/updating  the 
common  tactical  data  base  will  have 
to  oe  based  on  the  software  design 
of  the  field  computer  system. 

•  The  preprocessing  functions  In 
preparation  for  an  exercise  of  the 
battle  simulation  will  have  to 
Include  the  added  task  of 
initializing  the  third  data  base. 
This  task  is  visualized  as  being 
incorporated  in  the  Phase  II 
Preprocessing  Program.  The 
initialization  would  ordinarily  be 
made  consistent  with  the  Blue 
Special  Situation  and  the  research 
objectives  set  forth  for  the 
exercise. 


4.1.2  Human  Errors  in  the  Staff  Processing 

A  second  refinement  is  now  made  to  the  picture  of  the 
tactical  information  flow  in  the  battle  simulation.  This  refinement 
delineates  those  segments  of  the  flow  cycle  where  the  separate 
classification*;  of  human  errors  become  involved. 

The  second  modification  to  the  information  flow  diagram  is 
shown  in  Figure  4-3.  The  figure  now  shows  that  data  errors  and 

procedure  errors  can  occur  at  any  point  between  the  receipt  of  a 
tactical  information  message  by  the  staff  module  and  the  end  of  the 
staff  processing  when  the  module  transmits  its  decision  to  the 

appropriate  addressees  on  the  battlefield.  The  figure  also  shows  that 

cognition  errors  can  occur  only  during  the  second  stage  of  the 

processing  where  the  decision-maker  himself  performs  the  higher  level 
operations  on  the  tactical  information.  The  segments  of  human  error 
involvement  are  based  on  the  oo i nts-cf-occurrence  material  from 
paragraph  3.3. 
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STAFF  COORDINATION  STAFF  PROCESSING  STAFF  COORDINATION 


FIGURE  4-3.  TACTICAL  INFORMATION  FLOW  SHOWING  HUMAN  ERROR  REGIMES 


The  areas  of  error  involvement  given  in  the  figure  should 
be  interpreted  as  the  areas  where  error  effects  can  occur  with  some 
non-zero  probability.  The  arrows  should  not  be  taken  to  mean  that  the 
probability  is  uniform  from  one  end  to  the  other.  It  will  be  shown 
later  in  this  section  that  the  simulated  occurrences  of  human  errors 
to  be  incorporated  in  the  simulated  staff  modules  will  be  based 
insofar  as  possible  on  calculated  probabilities  which  change  from  one 
processing  step  to  the  next  In  accordance  with  the  three  factors  given 
in  paragraph  3.3.2.  The  Indicated  regimes  denote  some  non-zero 
probability  of  occurrence;  the  actual  probabilities  will  vary  from 
step  to  step  in  the  simulated  staff  processing. 

It  should  also  be  noted  that  Figure  4-3  exhibits  fcr  the 
first  time  the  Interface  boundaries  of  the  staff  modules.  The 
boundaries  are  the  dotted  lines  coincident  w*Ah  the  beginning  and  the 
ending  of  data  and  procedure  error  effects.  They  represent  the 
base-line  boundary  locations  delineating  the  entire  staff  processing 
event  sequence  shown  in  each  of  the  staff  procedure  categories  In 
Section  3.  The  ability  to  relocate  the  boundary  positions  so  that  the 
live  staff  modules  encompass  only  a  selected  portion  of  the  staff 
procedures  is  the  subject  of  the  next  section.  Under  the  base-line 
locations  shown,  the  live  staff  procedures  now  include  all  the 
low-level,  repetitive  operations  which  may  serve  to  detract  from  the 
desired  thrust  of  some  behavioral  research  experiments. 

4.2  CLASS  1  EVENT  LOGIC 

The  discussion  thus  far  has  taken  the  two  areas:  (1)  human 
errors  in  command  and  co>.crol  and  (2)  the  detailed  structure  of 
division  staff  processes,  and  merged  them,  in  order  to  focus  on  the 
behavioral  research  experiments  that  might  be  run  using  the  Integrated 
Division-Level  Battle  Simulation.  The  preliminary  material  in  this 
section,  furthermore,  has  served  to  sharpen  the  focus  by  showing  where 
and  how  substandard  human  performance  perturbs  the  tactical 
Information  flow  cycle  in  a  combat  situation.  This  subsection  now 
shows  how,  in  the  framework  of  the  complicated  structure,  the  computer 
can  be  made  to  simulate  the  staff  processing  in  such  a  manner  that  the 
investigators/control lers  may  control  the  incidence  of  substandard 
staff  performance  in  simulated  modules.  With  a  research  tool  of  this 
kind,  where  the  investigator  can  manipulate  the  simulated  staff 
performance  that  is  part  of  the  environment  the  live  players  will 
face,  a  wide  range  of  behavioral  experiments  can  be  run. 

The  key  element  in  this  kind  of  model  Is  the  logical 
structure  of  the  Class  1  events.  Class  1  events  were  Identified  in 
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the  original  Phase  1  design  as  the  staff  processing  occurrences  within 
the  Individual  simulated  staff  modules.  The  list  of  such  events  has 
now  been  completed  and  the  structured  sequences  making  up  thu- 
different  categories  of  staff  actions  have  been  specified  In  Section  3 
of  this  report.  The  level  of  detail  with  which  the  simulated  staff 
processing  will  be  treated  has  also  been  fixed;  Class  1  events 
represent  elementary  staff  operations  performed  by  one  person.  The 
discussion  now  shows  how  the  computer  logic  for  these  events  should  be 
approached  in  order  to  provide  the  flexibility  of  control  required 
above. 


4.2.1  Principles  of  the  Approach 

The  proposed  general  approach  to  Class  1  event  logic  Is  to 
develop  algorithms  oriented  to  the  individual  information-processing 
or  decision-making  operations  performed  by  human  beings.  The 
algorithms  will  make  reference  to,  and  operate  on,  selected  items  of 
tactical  data  from  the  input  message,  the  section  data  base,  and/or 
the  Blue  perceived  data  base,  in  accordance  with  definitions  of  the 
elementary  operations.  The  algorithms  will  also  inject  human  data  and 
procedure  errors  (but  not  cognition  errors)  on  a  chance  basis, 
governed  by  sets  of  computed  probabilities  that  will  depend  on  the 
nature  of  the  Individual  operations,  the  nature  of  the  data,  and  the 
workload  environment  at  the  time.  The  probability  calculations  will 
contain  a  control  factor  that  is  set  by  the  investigatcr/controller 
prior  to  the  exercise.  The  control  factor  will  allow  the  user  to 
preset  the  incidence  of  occurrence  of  data  and  procedure  errors,  but 
not  to  pinpoint  the  operations  or  times  at  which  they  occur. 

This  kind  of  logic  in  the  Class  1  events  will  serve 
adequately  in  simulating  the  low  leyel  staff  processing  operations  and 
even  certain  sequences  of  dec  si  on-making  operations  where  the  human 
deci sion-maker ‘ s  perception  of  the  problem  and  his  decision 
alternatives  are  more-or-less  routine.  The  logic  Is  clearly 
inadequate  and  incomplete,  however,  for  simulating  the  higher  level 
decision-making  operations  when  the  decision-maker  Is  faced  with  a 
complex  command  and  control  problem.  The  computer,  even  If  it  used 
new  artificial  intelligence  techniques,  cannot  be  programmed  to  model 
such  processes  of  the  human  brain  as  generation  of  a  perception  of  the 
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situation,  hypothesizing  the  missing  elements  In  a  pattern  or  picture, 
synthesizing  the  weighting  factors  associated  with  a  set  of 
alternatives,  or  selecting  the  best  course  of  action.  The  autonomous 
algorithms  described  above,  at  least  for  some  of  the  higher  level 
staff  processing  operations,  must  provide  some  kind  of  mechanism  for 
letting  the  Investigator/controller  Intervene  and  direct  the 
cerebrations  of  the  simulated  staff  officer. 

The  general  approach  to  Class  1  event  logic,  therefore, 
will  be  based  on  separate,  self-contained  routines  for  each  defined 
event,  but  with  the  added  feature  In  certain  sequences  for  triggering 
the  Interactive  participation  of  the  Investlgator/controller  to  guide 
the  decision-making  operations.  Thus  the  approach  will  divide  the 
Class  1  events  Into  two  subclasses  as  follows: 

t  Class  1A  Events  -  those  events  In  which 
the  simulated  operation  Is  explicitly 
represented  and  Includes  the  chance 
occurrence  of  data  errors  and  procedural 
errors. 

•  Class  IB  Events  -  those  events  which  will 
function  like  Class  1A  events  unless  the 
tactical  Importance  of  the  staff  action 
calls  for  controller  Intervention.  If 
controller  Intervention  Is  signalled, 
then  the  simulated  operation  will  be 
effected  by  Interactive  Input  from  the 
controller. 

These  subclass  distinctions  provide  the  basis  for  the  more  detailed 
discussion  presented  In  subsequent  paragraphs.  The  approach,  however, 
Involves  two  basic  operational  features  In  the  model  that  bear  on  Its 
essential  cost-effectiveness  as  a  research  tool  for  behavioral 
experiments.  The  first  is  the  Monte  Carlo  technique  to  be  employed  In 
the  random  occurrence  or  human  errors.  The  second  Is  the  trade-off 
tha.  exists  In  using  controller  Intervention  as  the  means  to  simulate 
stafr  processing  In  the  simulated  staff  modules.  These  features  are 
discussed  before  the  logical  structures  of  Class  1A  and  IB  events. 

4.2. 1.1  Monte  Carlo  Technique  for  Human  Error  Occurrence 

The  Phase  1  design  placed  considerable  emphasis  on  the 
capability  of  the  model  to  provide  "the  basis  for  repeated  exercises 
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of  the  same  experiment,  carried  out  under  Identical  conditions  but 
using  different  human  players."  The  battle  simulation  had  to  present 
the  same  division-level  combat  situation  to  successive  teams  of 
players  whether  the  exercise  was  oriented  to  a  behavioral  research 
experiment,  to  a  combat  developments  application,  or  to  a  training 
problem  for  division  staff  personnel.  This  "repeatability" 
requirement  was  largely  satisfied  through  the  proposed  use  of  the 
SCENARIO  File  which  was  a  permanent  Information  storage  medium  such  as 
a  magnetic  tape  or  computer  disk  and  on  which  was  recorded  not  only 
the  fully  Initialized  real  world  data  base  and  Blue  and  Red  perceived 
data  bases  but  also  the  Input  control  parameters  consistent  with  the 
specific  objectives  of  the  exercise. 

The  Introduction,  here  In  the  Phase  2  study,  of  the  Idea  of 
Monte  Carlo  techniques  to  control  the  Incidence  of  human  errors  In  the 
simulated  staff  processing  presents  a  problem  In  maintaining  the 
repeatability  of  experiments.  If  a  random  number  generator  Is  used  to 
"roll  the  dice"  with  respect  to  the  occurrence  of  human  errors,  how 
can  the  model  be  made  to  present  the  Identical  occurrences  In  the  same 
simulated  staff  actions  In  successive  exercises?  Most  Monte  Carlo 
simulations  are  structured  so  that  successive  runs  of  the  computer 
program  provide  different  results,  and  the  overall  result  must  be 
derived  from  the  statistical  ensemble  of  many  separate  runs.  On  the 
other  hand,  here  In  the  battle  simulation  It  Is  required  that  the 
pattern  of  random  human  errors  In  the  simulated  modules  be  repeated  In 
successive  exercises. 

According  to  the  general  approach  described  above,  each 
Class  1A  algorithm  will  contain  a  random  number  test  for  possible 
occurrence  of  a  data  or  procedural  error.  The  test  may  be  expressed 
as: 


where  R  Is  a  random  number  between  0  and  1,  and 
Pg  Is  the  computed  probability. 

If  the  test  Is  successful,  the  algorithm  will  Invoke  the 
appropriate  error  effect.  A  data  error  will  Inject  a  selected  Item  of 
erroneous  or  misleading  tactical  data.  A  procedural  error  will 
lengthen  the  simulated  time  Interval  for  the  completion  of  the 
elementary  operation. 

If  the  test  falls,  the  algorithm  will  simply  reflect  no 
occurrence  of  the  human  error. 
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The  requirement  for  repeatability  of  experiments  means  that 
the  "throw  of  the  dice"  given  by  the  random  number  R  must  be  the  same 
in  successive  exercises  so  that  If  the  simulated  module  encounters  the 
same  staff  processing  sequence  for  the  same  Input  tactical  message  It 
will  reflect  the  same  pattern  of  errors.  Of  course,  the  computed 
probability  Pfi  can  In  principle  be  Influenced  Indirectly  by  the  live 
players  and  tnereby  modify  the  pattern  of  errors.  For  example,  a  live 
staff  module  could  stimulate  the  "paper  mill"  processing  actions  of 
the  simulated  module  and  Increase  Its  workload.  Since  the  workload 
experienced  by  the  simulated  section  Is  one  of  the  factors  governing 
the  calculated  probability,  the  random  number  tests  would  reflect  a 
different  pattern.  But  Insofar  as  the  random  number  phasing  Is 
concerned,  the  battle  simulation  should  continue  to  provide  for  the 
repeatability  of  exercises  based  on  the  same  SCENARIO  File. 

4.2. 1.2  Controller  Intervention 

The  Phase  1  design  Introduced  the  Idea  of  controller 
Intervention  by  stating  that  "there  will  always  be  certain  Class  1 
events  and  Class  5  events  In  which  the  control ler(s)  must  Intervene  In 
order  to  supplement  the  logical  rules  of  the  simulation  or  to 

Influence  the  onslaught  of  events  on  a  populated  staff  module.  These 

Class  1  or  Class  5  events  are  therefore  further  qualified  as  release 

events,  because  the  control ler(s)  must  execute  their  release,  that  Is, 
complete  the  Intervention  on  or  before  the  time  of  occurrence  as 
measured  on  the  simulated  clock?" 

"Controller  Intervention  by  means  of  release  events  Is  one 
of  the  key  features  of  the  model.  Although  some  types  of  release 
events  are  simply  a  convenient  means  for  handling  certain  kinds  of 
staff  Inputs  to  populated  modules,  the  basic  reasoning  behind  most 
release  events  Is  as  follows: 

•  Release  events  provide  a  means  for  the 

Investigator/controller  to  Influence  the 
play  In  order  to  direct  the  exercise 
toward  the  research  objectives. 

•  Release  events  provide  a  means  for  a 

human  being  to  provide  certain  processes 
such  as  terrain  analysis,  Identification 
of  routes  of  advance,  etc.  which  would 
otherwise  call  for  much  larger  computer 
data  requirements . 
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t  Release  events  provide  a  means  for  the 
controlled  s)  to  Invoke  military 
judgement  In  certain  parts  of  the 
simulated  battle. 


The  Implementation  of  release  events  will  begin  by 
Identifying  all  those  occurrences  among  the  Class  1  and  Class  5  events 
where  controller  Intervention  Is  required.  Provision  must  then  be 
made  that  the  progenitors  of  these  events  trigger  the  pending  action 
warning  to  the  terminal  oprator.  Each  Identified  release  event  must 
then  be  provided  with  Its  own  formatted  screen  and  edit/update  routine 
through  which  the  terminal  operator  will  enter  the  requisite  data  for 
release.* 


Thus  the  Phase  1  design  anticipated  the  requirement  for 
controller  Intervention  In  the  higher  level  decision-making  operations 
In  the  simulated  staff  modules.  The  Class  1  events  In  which  the 
controller  must  Intervene  arc  the  Class  IB  events  discussed  below. 

The  central  problem  with  release  events,  however,  lies  In 
the  overall  burden  of  control  functions  that  must  be  carried  by  the 
controlled s)  during  the  running  of  exercises.  In  order  for  the  basic 
design  to  be  directed  toward  a  cost-effective  research  tool,  the  Phase 
l  report  stressed  the  Idea  of  minimizing  the  control  functions  so  that 
exercises  could  always  be  managed  and  directed  by  no  more  than  two 
qualified  personnel.  Release  events  represent  a  particularly 
stressful  part  of  the  controller's  responsibilities  because  the 
Interactive  release  of  the  events  Is  subject  to  the  timing 
requirements  established  by  the  event-oriented  computer  routine. 
Under  a  real-time  exercise,  for  example,  the  controller  would  be 
required  to  effect  the  release  of  the  engagement  cycle  event  (no.  508) 
every  15  minutes  for  each  separate  combat  engagement  on  the 
battlefield.  Each  such  release  might  require  Input  data  reflecting 
the  routes  of  advance  or  withdrawal  of  the  opposing  forces  ’;a11ored  by 
the  controller's  military  judgement  of  the  situation. 

Mow,  under  this  general  approach  to  simulated  staff 
processing,  the  controller! s)  will  also  have  to  effect  the  release  of 
Class  IB  events  vrftenever  the  computer  determines  that  the  tactical 
Importance  of  the  action  Is  critical  to  the  simulated  outcome. 
Although  the  trigger  thresholds  for  determining  the  decision-making 
release  events  will  be  adjustable  through  Input  data,  the 


6  Op  clt,  01 vision-level  Battle  Simulation, 
pg.  4-61. 
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controller(s) ,  during  an  exercise,  will  necessarily  rely  or  the 
pending  action  warning  associated  with  release  events,  because,  unlike 
the  cyclic  pattern  of  engagement  events  described  above,  the  timing  of 
the  Class  IB  events  will  not  be  easily  anticipated. 

4.2.2  Class  1A  Events 


Class  1A  events  are  staff  processing  events  that  simulate 
the  execution  of  Individual  elementary  operations.  Their  logical 
structures  will  represent  explicitly  the  Information  processing  and 
decision  making  operations  performed  either  by  human  beings  (as  In  a 
manual  staff  system)  or  by  field  computer  (as  In  an  ADP-assisted 
system).  The  separate  algorithms  will  operate  on  the  tactical  data 
associated  with  the  Input  message,  the  section  data  base,  and/or  the 
Blue  perceived  data  base,  and  will  simulate  the  amount  of  time 
necessary  to  complete  the  operational  step.  The  algorithms  will  also 
employ  the  random  number  tests  for  the  chance  occurrence  of  data 
errors  or  procedure  errors  as  described  In  paragraph  4.2. 1.1. 

There  w*!l  be  a  separate  algorithm  for  each  Class  1  event 
listed  fn  Table  3-1 

Those  algorithms  associated  with  Level  V  and  VI  operations 
will  contain  additional  logical  structure  which  will  determine  whether 
the  staff  action  Involves  a  sufficiently  significant  departure  from 
normal  routine  to  warrant  controller  Intervention.  Such  events,  of 
course,  are  Class  IB  events.  The  controller's  intervention  to 
substitute  for  the  decision-maker's  cognitive  processes  Is  discussed 
further  below.  But  If  the  logic  determines  that  the  Level  Y  or  YI 
operations  are  more-or-less  routine  in  nature,  then  the  remainder  of 
the  algorithm  Is  just  like  that  of  a  Class  1A  event. 

The  distinction  between  Class  1A  events  and  Class  IB  events 
Is  Illustrated  In  Figure  4-4.  This  figure  Is  a  macro  logical  flow 
diagram  of  the  algorithm  for  Event  150  -  EVALUATE  IN  CONTEXT.  The 
elementary  operation  Is  a  Level  V  In  which  the  decision-maker 
determines  whether  formal  staff  action  Is  required  at  the  time  (l.e., 
event  time)  when  he  first  becomes  aware  of  the  Input  message.  The 
elementary  operation  can  be  seen  to  be  part  of  Staff  Action  Categories 
1,  2,  and  3  (Figures  3-2,  3*4,  and  3-5).  In  these  event  threads  there 
are  two  possible  outcomes  from  the  execution  of  the  operation:  either 
formal  staff  action  is  initiated  or  else  the  action  started  by  the 
receipt  of  the  Input  message  is  terminated. 
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FIGURE  4-4.  LOGICAL  FLOW  OiAGRAM  OF  EVALUATE  IN  CONTEXT 
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EVALUATE  IN  CONTEXT  Is  a  Class  IB  event  because  there  are. 
In  all  three  categories,  input  tactical  messages  spelling  out 
significant  departures  from  routine  staff  activity.  Examples  are  as 
follows: 


t  In  Category  1:  G2  receives  an  NBC 
Report. 

•  In  Category  2:  G3  receives  a 
retransmitted  copy  of  a  Combat 
Intelligence  Report. 

•  In  Category  3:  G1/G4  receives  s 
non-concurring  chops  response  from  G3. 

In  each  of  these  staff  actions  the  cognitive  processes  required  of  the 
simulated  decision-maker  must  be  provided  through  controller 
Intervention. 

In  the  diagram,  the  logical  flow  on  the  right-hand  branch 
Is  the  added  structure  provided  In  a  Class  IB  event.  The  left-hand 
branch,  and  the  remainder  of  the  boxes  are  the  required  structure  for 
all  Class  1A  events. 

One  Important  logical  property  should  be  noted  In  the 
algorithm  for  EVALUATE  IN  CONTEXT.  If  the  computer  decides  that  the 
tactical  Importance  of  the  action  calls  for  controllers  Intervention, 
the  determination  of  whether  formal  staff  action  Is  required  becomes 
automatic.  The  simulated  decision-maker  will  always  "decide"  on 
Immediate  formal  staff  action  whenever  the  action  Is  mo^e  than  routine 
staff  processing. 

4.2.2. 1  Using  Computerized  Section  Oata  Bases 

The  discussion  above  makes  clear  that  all  Class  I  events 
will  be  Implemented  by  computer  routines  containing  the  required. 
Class  1A  logical  structures.  Only  a  small  number  of  the  routines  will 
possess  additional  Class  IB  logical  structures  providing  the  automatic 
switch  for  controller  Intervention  to  substitute  for  the 
decision-maker' s  cognitive  processes.  The  question  now  arises;  how 
will  the  Class  1A  logical  structures  operate  If  the  simulation 
software  provides  for  section  data  bases?  As  stated  in  the  last 
subsection,  section  data  bases  are  the  bodies  of  Information  In  tne 
separate  staff  sections  from  which  the  decision-makers  generate  their 


perceptions  of  problems  and  ultimately  base  their  tactical  decisions. 
Each  staff  section  organizes  Its  section  data  base  according  to  Its 
own  area  of  functional  responsibility.  In  a  manual  staff  system,  a 
section  data  base  consists  of  the  filing  cabinets,  tote  board 
displays,  situation  maps,  etc.,  all  organized  (and  used)  according  to 
particular  area  of  responsibility  of  the  staff  section.  How  suppose 
the  simulation  software  provided  computer  files  that  were  organized 
and  filled  with  tactical  data  In  a  manner  emulating  a  real  staff 
section  under  a  manual  mode.  How,  In  this  framework,  would  the 
simulated  staff  modules  work? 


The  simulated  staff  processing  using  the  third  data  base 
will  be  based  on  Class  1A  logical  structures  which  will  explicitly 
modify,  update,  and  retrieve  tactical  data  In  the  section  data  bases 
according  to  the  definitions  of  the  elementary  operations.  This  means 
that  those  operations  associated  with  putting  data  Into  the  section 
data  buses  will  explicitly  add  more  tactical  data  Items  or  else  update 
existing  Items;  and  those  operations  associated  with  data  extraction 
will  explicitly  read  the  data  from  Its  appropriate  computer  fllo.  The 
operations  related  to  the  former  are  hereafter  called  update 
operations.  They  are  as  follows: 

t  Event  Ho.  125  EHTER 

t  Event  Ho.  126  TILE 

t  Event  Ho.  133  POST  or  PLOT 


These  are  the  only  operations  In  which  data  are  put  Into  the  section 
files/ displays*.  The  second  and  third  Items  In  the  list  Involve  a 
wide  variety  of  different  data  repositories  across  the  five  staff 
sections.  The  operations  Involved  with  aata  extraction  are  hereafter 
called  retrieval  operations.  They  are  as  follows: 


« 

t 

t 

c 


Event  Ho.  134 
Event  Ho.  141 
Event  Ho.  150 
Event  Mo.  151 


RETRIEVE 

COORD I HAT I OH  COMPLETE? 
EVALUATE  IH  COMTE XT 
SYHTHESI2E  DATA 


These  are  the  only  operations  in  which  data  are  read  out  of  the 
appropriate  repositories*.  The  remainder  of  the  operations  may 
Involve  manipulation  of  tactical  data  from  Input  messages,  or  data 
Items  already  extracted  from  the  section  data  base,  or  simply 
procedural  rules  to  be  followed  In  staff  processing;  they  do  not 
Involve  the  explicit  update  or  retrieval  of  data  from  the  third  data 
base. 

*  The  reader  Is  reminded  that  tMs  section  treats  simulated 
staff  modules  only.  In  populated  modules  the  cognitive 
elementary  operations  may  involve  additional  access  to  files. 
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4. 2*2,2  Without  the  Section  Data  Bases 

If  the  software  design  does  not  provide  computer  files  for 
the  third  data  base,  the  Class  1A  logical  structures  for  the  update 
and  retrieval  operations  will  have  to  be  set  up  In  a  different  manner. 
The  update  operations  will  not  Involve  the  explicit  placement  of  data 
Items  In  an  appropriate  data  repository;  instead  the  algorithm  will 
simply  mark  time  to  simulate  the  time  necessary  to  complete  the 
operation*  The  tactical  data  Items  contained  In  input  tactical 
messages  will  already  be  resident  In  the  perceived  data  base  at  the 
times  the  messages  are  received  by  the  staff.  The  tactical  data  Items 
constituting  the  staff  output  frag  orders  will  be  lost  In  the  sense 
that  after  the  frag  orders  have  been  transmuted  to  the  addressee!  s) 
In  the  BOG,  there  will  be  no  repository  of  data  representing  the  file 
copies  of  issued  orders. 

The  retrieval  operations  will  have  to  access  tactical  data 
from  the  perceived  data  base.  Without  a  third  data  base,  tne  only 
body  of  Information  that  can  represent  the  section  files/ displays  Is 
the  body  of  unaggregated  tactical  data  In  the  second  data  base. 
Although  the  algorithms  can  be  structured  so  that  they  aggregate  (or 
reaggregate)  the  tactical  Information  according  to  the  retrieval 
format  requirements,  the  Information  in  the  perceived  data  base  may 
very  likely  have  changed  at  the  time  of  retrieval.  As  stated  In 
paragraph  4.1.1. 2,  the  perceived  data  base  will  change  dynamically 
throughout  the  simulated  conflict  in  a  manner  more-or-less  independent 
of  any  actions  taken  by  the  personnel  (or  machines)  In  the  division 
staff.  Simulated  staff  processing  under  this  stilted  framework  can  be 
Illustrated  by  the  following  vignette: 

At  1000  hours,  the  G3  receives  a  SITREP  from  the  first 
brigade.  After  noting  that  there  are  no  significant 
changes  In  the  first  brigade  situation,  he  files  the 
report  so  that  It  may  be  used  when  the  Division  SITREP 
Is  to  be  prepared.  The  update  operation  FILE  Is 
simulated  by  marking  off  a  completion  time  of  one  minute 
without  any  explicit  transfer  and  storage  of  tactical 
data.  At  1130  he  embarks  on  the  preparation  of  the 
Division  SITREP.  in  synthesizing  the  data  for  the 
report,  he  withdraws  from  file  the  brigade  SITREP 
received  at  1000  hours.  The  retrieval  operation 
SYNTHESIZE  DATA  is  simulated  by  accessing  the  perceived 
data  base  and  reformatting  the  first  brigade  SITREP  from 
the  tactical  data.  However,  the  precise  contents  of 
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this  reconstructed  report  may  not  be  tne  same  as  that 
received  at  1000  hours.  During  the  Intervening  90 
minutes  of  simulated  combat,  the  data  of  the  perceived 
data  base  could  reflect  a  considerable  difference  In  the 
situation  for  the  first  brigade.  While  one  might 
conclude  that  the  reconstructed  report  represents  an 
improved  basis  for  preparing  the  Division  SITREP,  the 
updated  situation  report  actually  represents  a 
distortion  of  reality  In  the  simulated  staff  processing. 


4.2.3  Class  IB  Events 


The  Class  IB  logical  structures  will  provide  the  mechanism 
which  allows  the  Investigator/ controller  to  Intervene  and  substitute 
for  the  decision-making  operations  In  a  simulated  staff  module.  The 
mechanise  will  consist  of  three  parts,  as  follows: 

•  Discrimination  logic  to  determine 
whether  the  staff  action  Involves 
sufficient  departure  from  routine  to 
warrant  controller  Intervention. 

•  A  means  to  display  a  pending  action 
warning  for  the  controller.  This 
warning  must  be  posted  some  five  or  ten 
minutes  before  the  release  event  Is 
scheduled  to  occur. 

•  A  routine  providing  Interactive  data 
entry  procedures  by  which  the  controller 
effects  the  release  of  the  decision  made 
by  the  simulated  decision-maker. 

The  first  two  parts  of  the  mechanism  as  well  as  certain  preparatory 
aspects  of  the  third  are  Illustrated  as  macro  logic  boxes  In  Figure 
4-4, 


Class  IB  logical  structures  will  encompass  a  slightly 
different  thread  of  Class  1  events  in  each  of  the  seven  staff  action 
categories.  Category  5  Actions  (c1gu re  3-7)  will  never  Involve 
controller  Intervention  at  all.  In  each  of  the  remaining  categories 
these  will  be  three  events  delineating  the  sequence  of  decision-making 
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operations  that  the  controller  will  direct.  The  first  event  Is  the 
“trigger*  event  tfileh  contains  the  discrimination  logic  and  which 
posts  the  pending  action  warning  for  the  controller  If  Intervention  Is 
required.  The  second  event  Is  the  release  event  Itself  whose  release 
must  be  effected  by  the  controller  on  or  before  the  time  of  the  event. 
The  third  event  is  the  last  decision-making  operation  In  the  sequence 
before  the  simulated  processing  reverts  back  to  wholly  Class  1A  logic 
structures.  Table  4-1  Identifies  the  three  events  for  each  of  the 
relevant  staff  action  categories. 

The  general  requirements  for  the  controller's  release 
routine  will  Involve  special  edit/update  software  and  special 
formatted  display  screens.  A  trade-off  will  exist  between  the  human 
engineering  requirements  for  simple  keyboard  procedures  and  the 
limited  display  screen  size  and  core  space  In  the  computer.  The 
Information  displayed  to  the  controller  when  he  must  release  a 
decision  will  have  the  following  special  requirements: 

t  It  must  show  the  staff  action  category 
and  type  of  tactical  message  that  has 
trl ggered  the  decision-making. 

t  It  must  show  the  critical  decision 

elements  which  the  decl s Ion-maker Ts 
addressing. 

•  The  critical  decision  elements  must 

reflect  all  the  data  errcrs  that  might 
exist  In  the  decision-maker' s 

perception. 

•  It  must  show  the  alternative  procedural 

choices  open  to  the  decision-maker.  Tor 
example.  In  the  formal  staff  processing 
of  a  tactical  message  from  the  BOG, 

there  are  three  alternative  procedural 
choices  In  the  decision-maker's 

operation  EVALUATE  DATA. 

•  It  must  provide  for  the  Insertion  of  a 
cognition  error. 

a  It  must  provide  for  the  keyboard  entry 
of  the  selected  action. 
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TABLE  4-1 . 

CLASS  IB  LOGICAL  STRUCTURES  IN  THE  STAFF  ACTION  CATEGORIES. 


Staff  Action 
Category 

"Trigger 11  Event 

Release  Event 

End  of  Sequence 

1 

Event  No.  ISO 
EVALUATE  IN  CONTEXT 

Event  No.  152 
EVALUATE  DATA 

Event  No.  165 
SELECT  ACTION 

2 

Event  No.  150 
EVALUATE  IN  CONTEXT 

Event  No.  152 
EVALUATE  DATA 

Event  No.  165 
SELECT  ACTION 

3 

Event  No.  150 
EVALUATE  IN  CONTEXT 

Event  No.  152 
EVALUATE  DATA 

Event  No.  165 
SaECT  ACTION 

4 

INITIATE  BY  SELF 

Event  No.  152 
EVALUATE  DATA 

Event  No.  165 
SELECT  ACTION 

5 

• 

(none) 

)  Event  No.  152  Event  No.  154 

EVALUATE  DATA  EXTRAPOLATE  SITUATION 

or 

Event  No.  165 
SaECT  ACTION 

Event  No.  154 
EXTRAPOLATE  SITUATION 
or 

Event  No.  165 
SaECT  ACTION 


7  Event  No,  151  Event  No.  154 

SYNTHESIZE  DATA  EXTRAPOLATE 

SITUATION 


6  Event  No.  100 

INITIATE  BY  CLOCK 
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The  limited  screen  size  and  the  short  period  of  time  the 
controller  will  have  to  execute  the  release  of  the  decision  will 
preclude  the  display  and  provision  for  the  enumeration  of  action 
alternatives  and  the  evaluation  criteria  to  be  used  In  the  action 
selection.  The  controller  will  have  to  assimilate  these  aspects  of 
the  process  from  his  knowledge  of  the  on-going  simulated  conflict. 

4.2.3. 1  Cognition  Errors 

Unlike  data  errors  and  procedure  errors,  both  of  which  .dll 
be  simulated  by  means  of  a  Monte  Carlo  process,  cognition  errors  will 
be  simulated  by  explicit  keyboard  Insertion  during  the  release  of  a 
decision.  The  frequency  of  occurrence  of  such  errors  as  well  as  the 
substantive  meaning  In  terms  of  the  wrong  decisions  drawn  by  the 
decision-makers  will  be  handled  entirely  as  part  of  the  controller's 
Intervention. 

As  a  consequence  of  this  logical  structure,  simulated  staff 
processing  will  accommodate  the  occurrence  of  a  cognition  error  only 
If  the  action  Involves  critical  tactical  questions  ailing  for  a 
release  event.  Simulated  cognition  errors  will  never  occur  In 
more-or-less  routine  staff  actions  Involving  Class  1A  logical 
structures  by  themselves. 

4. 2. 3. 2  Internally  Initiated  Actions 

Category  4  Actions,  as  described  In  paragraph  3.2. 1.4,  are 
actions  that  are  spontaneously  Initiated  by  a  senior  staff  officer 
because  he  holds  a  perception  of  the  situation  or  problem  In  his  mind 
and  Is  spurred  to  act  on  It  at  once.  In  simulated  staff  modules 
Category  4  Actions  will  be  triggered  by  the  elementary  operation 
INITIATE  BY  SELF.  INITIATE  BY  SELF  will  require  special  treatment 
beyond  that  described  above  for  Class  IB  logical  structures.  In  order 
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to  simulate  Internally  Initiated  actions,  the  controller  will  be 
required  to  Insert  the  event  but  without  any  prior  timing  guidance 
from  the  simulator*  The  computer  software  cannot  be  made  to 
anticipate  the  moment  "when  the  light  comes  on"  In  the  mind  of  the 
simulated  decision-maker.  Consequently,  the  triggering  by  the 
controller  will  require  data  entry  of  both  the  timing  of  event  (when 
does  the  decision-maker  Inltate  the  action?)  and  the  subject  matter 
(what  Is  the  problem  he  Is  addressing?).  It  Is  assumed  that  such 
entries  will  always  be  made  In  the  dynamic  framework  of  the  event 
progression  observable  by  the  controller  and  with  the  basic  objectives 
of  the  exercise  firmly  In  mind. 

4.3  CONCLUSIONS  ON  SIMULATED  STAFF  PROCESSING 

On  the  basis  of  the  considerations  brought  out  In  Section 
2,  Section  3,  and  the  preceding  discussion  of  this  section,  It  Is 
concluded  that  the  first  added  design  requirement  of  the  Phase  2 
study,  namely,  to  structure  the  simulated  staff  modules  In  the  model 
so  that  they  can  accomnodate  variant  human  staff  performance  Is 
achievable  with  certain  qualifications.  Software  can  be  developed 
that  will  simulate  the  staff  processing  In  the  event  thread  framework 
specified  by  the  staff  action  charts  In  Section  3.  These  routines  can 
be  tied  to  certain  Input  parameters  that  will  provide  (1)  Investigator 
control  of  the  simulated  human  staff  performance  and  (2)  Investigator 
control  of  the  simulated  staff  response  times.  The  first  set  of 
parameters  will  allow  behavioral  scientists  to  establish  the  human 
performance  environment  for  the  live  players  in  populated  modules;  the 
second  set  will  allow  the  model  to  be  exercised  either  under  a  manual 
staff  system  or  else  In  a  staff  system  using  ADP  assistance. 

The  salient  operational  characteristics  of  simulated  staff 
modules  are  presented  below,  first  for  a  manual  staff  system  and 
second  for  a  staff  system  provided  with  ADP  assistance.  The 
qualifications  attendant  on  these  conclusions  follow  thereafter. 

4.3.1  Simulated  Staff  Processing  In  a  Manual  System 

The  simulated  staff  modules  can  be  made  to  operate  with  the 
following  properties  for  a  manual  staff  system: 
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t  Realistic  time  delays  for  each 

elementary  operation.  The  median  time 
delays  may  De  preset  by  Input 
parameters. 

•  Random  occurrences  of  data  errors  and 
procedure  errors,  governed  by  other 
Input  parameters, 

t  Normal  coordination  and  review  responses 

If  the  populated  modules  make  errors  in 
their  staff  actions. 

•  Investlgator/controller  Intervention 
(with  release  events)  whenever  the 
simulated  decision-maker  must  address 
Important  tactical  decisions. 


4.3.2  Simulated  Staff  Processing  in  an  APP-As$1sted  System 

The  simulated  modules  can  be  made  to  exhibit  the  following 
properties  for  an  ADP-assIsted  staff,  based  on  the  same  software 

structures: 

•  Realistic  time  delays  for  each 
elementary  operation  but  with  rapid 
responses  for  machine  operations  and 
slower  responses  for  those  operations 
still  performed  by  human  beings. 

•  Random  occurrences  of  data  errors  and 
procedure  errors  but  only  for  those 
operations  performed  by  personnel . 

•  Input,  output,  coordination,  and  review 
processes  will  be  largely  automated,  but 
the  simulated  modules  will  exhibit 
normal  responses  If  the  live  modules 
make  errors  In  their  staff  actions. 

•  Controller  Intervention  as  described 
above. 
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Qualifications 


The  following  qualifications  are  associated  with  this 
approach  to  simulated  staff  processing: 

•  Insufficient  data  have  been  found  to 
exist  for  the  relative  frequencies  of 
occurrence  of  the  three  types  of  human 
errors . 

•  Insufficient  data  have  been  found  for 
human  performance  times  on  elementary 
operations  Involving  ADP  terminal 
devices. 

•  The  discrimination  logic  necessary  to 
determine  whether  controller 
Intervention  Is  substituted  for  the 
simulated  decision-maker  has  not  been 
fully  designed. 

•  The  critical  decision  elements 
associated  with  a  controller- Inserted 
decision  have  not  been  fully  identified. 

The  lack  of  applicable  error  analyses  may  well  be  a  blessing  In 
disguise  In  that  It  forces  the  simulation  design  to  accommodate  a  wide 
range  of  error  frequencies.  This  means  the  behavioral  researcher  will 
be  provided  with  considerable  flexibility  for  studying  human  error 
effects.  The  model  may  become  a  vehicle  for  accumulating  a  body  of 
needed  data  on  human  performance  In  staff  Information  processing.  The 
discrimination  logic  and  the  associated  decision  elements  will  require 
additional  work  They  will  be  addressed  In  more  detail  at  a  future 
date. 
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SECTION  5 


'..tr 


PRINCIPLES  OF  TASK  DESIGN 


5.0  INTRODUCTION 

This  section  develops  guidelines  for  the  design  and  implemen¬ 
tation  of  player  tasks  in  an  interactive  simulation.  The  approach 
to  this  development  assumes  that  an  existing  or  conceptual  tactical 
information  system  has  been  defined  and  is  being  emulated  on  an 
available  simulation  of  (division/corps  level)  battle.  It  is  further 
assumed  that  a  detailed  standard  operating  procedure  (SOP)  for  the 
populated  staff  module  in  the  system  being  emulated  has  been  specified. 
The  purpose  of  the  development  in  this  section  is  to  define  the  changes 
and/or  additions  to  such  a  specified  SOP  that  may  be  required  to  insure 
that  the  required  variables  are  controlled  or  are  measurable.  Trade¬ 
offs  among  task  realism,  credibility,  and  impact  on  performance  mea¬ 
surement  are  discussed.  Viewed  in  this  context,  task  design  is  in¬ 
extricably  interwoven  with  the  design  of  the  populated  modules  and 
with  experimental  design.  The  discussion,  therefore,  begins  with  the 
purpose  of  the  staff  system,  the  nature  of  staff  decision  making  and 
some  of  the  implications  therefrom.  It  then  examines  some  of  the 
trade-offs  developed  in  the  companion  volume  for  staff  module  design 
but  which  equally  affect  task  design.  Other  factors  affecting  task 
design,  to  include  simulation  design  and  purpose  of  the  experiment 
are  also  examined  as  a  basis  for  developing  principles  of  task  design. 

A  set  of  procedures  for  formulating  task  design  is  provided. 

5.1  PURPOSE  OF  STAFF  SYSTEM 

5.1.1  Staff  Functions. 

The  Staff  Officer's  Field  Manual^  states: 

•  "Command  is  the  authority  that  a  commander  in  the 
Military  Service  exercises  ove**  his  subordinates 
by  virtue  of  his  rank  or  assignment.  Command 
includes  the  authority  and  responsibility  for 
effectively  using  available  resources  and  for 
planning,  organizing,  directing,  coordinating ,  and 
controlling  military  forces  for  the  accomplishment 
of  assigned  missions.  The  commander  alone  is  re¬ 
sponsible  for  all  that  his  unit  does  or  fails  to 
do  .  .  .  He  is  assisted  in  performing  command 
functions  by  deputy  or  assistant  commanders  and  a 
staff  ..." 


U.S.  Department  of  the  Army,  Staff  Organization  and  Procedure, 
FM  101-5,  Washington,  July  1975^ 
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t  "The  staff  consists  of  officers  who  are  specifically 
ordered  or  detailed  to  assist  the  commander.  .  . 

Five  functions  are  common  to  all  staff  officers: 

-  Providing  information 

-  Making  estimates 

-  Making  recommendations 

-  Preparing  plans  and  orders 

-  Supervising  the  execution  of  plans  and 
orders." 

Clearly,  these  five  functions  are  cyclic  in  that  supervising  the 
execution  of  plans  and  orders  provides  new  information  which  can  be 
the  basis  for  continuing  the  cycle.  It  should  also  be  noted  that 
this  set  of  functions  falls  into  the  pattern  of  Class  1  (Staff 
Processing)  events  depicted  in  Figure  4-3,  i.e., 

Supervising  the  execution 
of  plans  and  orders  and 
providing  information 

Making  estimates  and  1  R  , .  Perception  and 

recommendations  f  esu  “  Decision  Making 

Preparing  plans  and  J  tQ  0utput  Processfng 

In  summary  then,  it  may  be  said  that  the  purpose  of  the  military  staff 
at  any  echelon  is  to  facilitate  human  decision  making. 

5.1.2  Nature  of  Military  Decision  Making. 

Paragraph  3.1  defined  the  elementary  operations  involved  in 
staff  information  processing  and  identified  the  higher  level  or 
cognitive  processes  which  are  the  essence  of  decision  making.  Para¬ 
graph  3.2  developed  the  sequence  in  which  these  operations  are  normally 
performed  in  processing  staff  message  traffic.  Paragraph  4.1  aggre¬ 
gated  these  operations  and  showed  that  they  clustered  into  the  opera¬ 
tions  required  to  maintain  and  update  section  files  and  displays,  the 
cognitive  processes  associated  with  decision  making,  and  the  processes 
required  for  output  processing.  This  is  illustrated  in  Figure  4-3. 

Now,  the  cognition  processes  (Level  V  and  VI  elementary  operations) 
can  operate  only  on  data  already  stored  in  the  decision  maker's  short 
term/operating  memory.  If  additional  data  are  needed  for  any  of  the 
processes,  the  cognition  processes  stop  until  the  needed  data  are 


Produces 


Section  Files/ 
Displays 
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retrieved  from  long-term  memory  or  the  environment  for  which  files 
and  displays  are  surrogates.  From  this  it  follows  that  the  principal 
purpose  of  the  staff  section  data  base  (particularly  the  visible  files 
and  displays)  is  to  extend  human  operating  memory  for  the  cognition 
processes.  In  fact,  if  such  aids  to  memory  are  not  provided,  the 
decision  makers  will  improvise  them. 

It  should  also  be  noted  that  most  formal  Army  instruction  in 
staff  operations  and  procedures  (primarily  at  the  Command  and  General 
Staff  College)  has,  in  the  past,  largely  concentrated  on  the  decision 
making  processes.  Because  of  the  high  quality  of  the  information 
provided  to  him  (even  though  it  may  be  incomplete  and  contain  uncer¬ 
tainties),  the  student  is  hardly  aware  of  the  decision  maker’s  de¬ 
pendence  on  the  lower  level  information  processing  functions.  He 
gains  the  impression  that  all  of  the  pertinent  information  generated 
at  subordinate,  adjacent,  and  higher  echelons  is  somehow  made  available 
to  decision  makers.  Not  until  he  has  had  field  experience  is  he  aware 
of  the  amount  of  hard,  grubby  labor  involved  in  creating  and  maintain¬ 
ing  a  useful  data  base.  On  the  other  hand,  the  discussions  in  Section  4 
clearly  show,  that  the  opportunity  for  error  and  delay  in  information 
processing  before  and  after  decision  making  is  far  greater  than  in 
the  actual  decision  making  and  the  impact  of  such  delays  and  errors 
on  combat  outcome  is  more  fundamental. 

It  follows  that  studies  and  research  in  the  area  of  military 
decision  making  cannot  be  limited  to  studies  of  the  decision  making 
functions  but  must  include  information  processes  to  include  their 
errors  anc  delays  as  well.  Further,  to  be  useful,  automation  must 
concentrate  on  supporting  the  decision  making  functions  by  providing 
pertinent,  coherent,  readily  available  data  for  decision  making  and 
assistance  in  the  cognitive  processes  as  well. 

5.1.3  Irrpl  ications. 

A  number  of  implications  pertinent  to  task  assignment  can 
be  drawn  directly  from  the  preceding  discussion: 

•  The  transfer  of  information  between  an  information 
system  or  a  simulation  thereof  and  a  live  decision 
maker  always  involves  lower  level  (I  -  IV)  informa¬ 
tion  processes. 

•  No  matter  where  you  place  the  man/simulation 
boundary  some  level  I  -  IV  processing  must  stiil 
be  performed  by  the  decision  maker  in  order  to 
transfer  data  from  the  system  to  his  short-term 
memory  and  vice-versa. 
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•  To  the  extent  that  the  decision  maker  participates 
in  the  lower  level  processes,  he  has  already  trans¬ 
ferred  significant  data  from  the  data  stream  into 
memory  and  thus  circumvented  the  formal  transfer 

of  data  from  a  message  or  file  when  it  arrives  before 
him  for  action.  By  the  same  toke,  to  the  extent  he 
is  precluded  from  participating  in  the  normal 
level  I  -  IV  processing,  he  must  add  such  processing 
to  transfer  data  into  his  short-term  and  long-term 
memory.  Such  preclusion  could  result  from  task 
assignment  in  the  manual  mode  or  from  system  design 
in  the  ADP-assisted  mode. 

•  Effective  decision  aiding  systems  will  effect  this 
transfer  more  efficiently  and  effectively  than  does 
participation  in  the  formal  manual  mode  processing. 

•  In  the  manual  mode,  decision  maker  participation  in 
lower  level  processes  permits  him  to  create  shunts 
from  these  lower  level  processes  to  the  cognition 
processes  without  waiting  for  the  completion  of  the 
lower  processes.  This  permits  tne  cognition  pro¬ 
cesses  to  be  initiated  sooner  and  to  be  carried 
out  in  parallel  with  the  lower  level  processes. 

Without  such  parallel  processing  the  manual  staff 
would  be  overwhelmed  by  even  a  modest  workload. 

•  Such  shunting  to  the  cognition  processes  tends  to 
reduce  reliance  on  files  and  displays  and  to  sub¬ 
stitute  reliance  on  memory. 

5.2  RESULTS  OF  TRADE-OFF  ANALYSES 

2 

In  Section  5  of  the  companion  volume  to  this  report  there 
is  a  series  of  analyses  of  the  trade-offs  involved  in  moving  the 
boundaries  of  a  populated  staff  module  toward  the  decision  maker  in 
order  to  reduce  the  cost  of  operating  such  a  module.  As  has  already 
been  indicated,  many  of  the  considerations  in  task  assignment  to 
personnel  in  the  populated  module  are  quite  similar  to  those  involved 
in  changing  module  boundaries,  i.e.,  in  moving  the  interface  between 
the  simulation  and  the  players.  For  example,  the  effect  on  the 
decision  maker(s)  in  the  module  is  much  the  same  if  the  module 
boundary  excludes  all  or  a  portion  of  the  lower  level  staff  processes 


2 

Tiede,  R.  V.,  Burt,  R.  A.  and  Bean,  T.  T.,  On  the  Design  of 
Simulations  of  Command  and  Control  Processes,  Science  Applications , 
Inc,.  McLean,  vA,  15  September  T352T 
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or  if  the  task  assignment  prescribed  for  the  decision  maker  precludes 
his  participation  in  those  processes.  It  is,  therefore,  worthwhile 
to  summarize  these  considerations  in  a  series  of  tables  (Tables  5-1 
through  5-7)  because  of  the  insights  they  provide  as  to  the  limitations 
of  these  different  configurations  and  to  facilitate  later  analysis  of 
the  control  and  measurability  of  variables  that  each  provides.  These 
tables  evaluate  each  of  seven  different  configurations  of  which  the 
first  five  are  variant  emulations  of  a  manual  staff  module  and  the 
last  two  are  emulations  of  an  ADP-assisted  staff  module.  Each  series 
of  tables  (5-1  and  5-6)  begins  with  a  configuration  in  which  all  of 
the  elementary  operations  performed  by  personnel  in  the  mode  being 
emulated  (manual  and  ADP-assisted,  respectively)  are  performed  by 
players.  The  succeeding  variants  eliminate  more  and  more  elementary 
operations  from  the  module  until  only  the  cognitive  functions  are 
being  performed  by  players;  all  the  rest  are  performed  within  the 
simulation.  (See  the  companion  volume  for  more  detailed  definitions 
of  the  various  configurations.)  The  task  assignment  analog  to  this 
would  be  a  series  of  task  assignments  for  the  decision  maker  which 
successively  prevented  him  from  participating  in  an  increasing  portion 
of  the  lower  level  processes. 

In  Tables  5-1  through  5-7,  the  different  configurations  are 
evaluated  with  respect  to  the  following  attributes: 

•  REALISM.  Each  variant  is  rated  in  terms  of  the 
degree  of  realism  with  which  it  is  possible  to 
replicate  the  operating  environment  of  the  staff 
module  being  emulated.  For  example,  in  Table  5-1 
the  configuration  is  one  in  which  all  elementary 
operations  performed  by  personnel  in  a  staff 
module  processing  information  in  a  manual  mode 

are  performed  by  players  and  it  is  rated  "Excellent" 
for  realism.  In  contrast,  T?b!e  5-5  evaluates  a 
configuration  in  which  players  perform  only  the 
cognitive  operations  of  the  same  manual  staff 
module.  It  is  rated  "Poor"  as  to  realism. 

•  MEASUREMENT.  Each  variant  is  rated  with  respect 
to  its  inherent  capability  to  measure  several  of 
the  performance  parameters  associated  with  behav¬ 
ioral  experiments.  These  include: 

-  PROCESS  TIMES,  i.e.,  the  length  of  time  re¬ 
quired  to  carry  out  each  elementary  operation 
which  presupposes  that  it  is  also  possible  to 


Ibid. 
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TABLE  5-1.  EVALUATION  OF  CONFIGURATION  A 


CONFIGURATION:  A 

SYSTEM  EMULATED:  Manual 

PLAYER  PERFORMED  EOs:  All 
REALISM:  Excellent 

MEASUREMENT  OF: 

PROCESS  TIMES: 

Lower  Level  Proces$es--Good.  All  measurable. 

Cognitive  Processes—Poor.  Shunting  prevents 
timing  "initiation;  transition  between  pro¬ 
cesses  not  identifiable  in  manual  mode. 

ERROR  RATES: 

Lower  Level  Drocesse$--Poor.  Under  high 
stress  conditions  which  are  of  great 
interest  for  error  phenomena,  there  will 
be  reluctance  to  reduce  voice  traffic  to 
hard  copy--hence,  no  standard  for  error 
detection. 

Cognitive  Processes--Poor.  With  voice 
communication  maximum  shunting  occurs, 
hence,  large  reliance  on  memory  and  no 
record  of  data  actually  used  in  decision 
making. 

ACCESSION  FREQUENCY: 

Poor.  High  shunting  rate  and  associated 
reliance  on  memory  prevent  measurement 
of  decision  maker  access  to  incoming  or 
stored  data. 

INPUT  VARIABLE  CONTROL:  Poor.  Two  factors  militate  against.  Vcice 
input  communication  requires  large  number  of  controllers  which 
inevitably  dilutes  control.  Voice  communication  (overhearing  traffic) 
makes  control  of  information  flow  within  staff  module  impossible. 

COST: 

PERSONNEL:  Exhorbitant 
HARDWARE/SQFTHARE:  Low 
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TABLE  5-2.  EVALUATION  OF  CONFIGURATION  B 

CONFIGURATION:  B 

SYSTEM  EMULATED:  Manual 

PLAYER  PERFORMED  EOs:  All  except  RECEIVE  and  TRANSMIT 

by  voice 

REALISM:  Good,  but  not  as  good  as  Configuration  A 

MEASUREMENT  OF: 


PROCESS  TIMES: 

Lower  Level  Processes--Good,  except  for 
RECEIVE  and  TRANSMIT  by  voice. 

Cognitive  Processes— Poor .  Shunting  still 
occurs  and  transition  between  operations 
not  identifiable  in  manual  mode. 

ERROR  RATES: 

Lower  Level  Processes— Good.  Hard  copy  pro¬ 
vides  sta nda r  d  for  error  detection. 

Cognitive  Processes—Poor,  To  the  extent 
shunting  still  occurs  because  of  decision 
maker  participation  in  lower  level  processes, 
it  is  not  possible  to  determine  what  data 
were  the  basis  for  decisions. 

ACCESSION  FREQUENCY: 

Poor  (♦).  Better  than  Configuration  A,  but 
to  the  extent  decision  makers  still  partici¬ 
pate  in  lower  level  processes,  shunting 
makes  it  impossible  to  measure  actual  data 
accessions. 

INPUT  VARIABLE  CONTROL:  Medium.  Significantly  better  than  Configura¬ 
tion  A,  but  some  uncontrolled  information  flow  (shunting)  still  occurs. 

COST: 

PERSONNEL:  Medium.  Significant  reduction  in  control 
personnel . 

HARDWARE/ SOFTWARE:  Medium 
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TABLE  5-3.  EVALUATION  OF  CONFIGURATION  C 


CONFIGURATION:  C 

SYSTEM  EMULATED:  Manual 

PLAYER  PERFORMED  EOs:  All  except  RECEIVE  and  TRANSMIT 

(VOICE)  and  INVISIBLE  FILES 

REALISM:  Medium.  Decision  maker  can  still  participate  in  some 

lower  level  processes  (Visible  Files),  but  his  accession  to  data  in 
invisible  files  must  be  far  more  structured. 

MEASUREMENT  OF: 

PROCESS  TIMES: 

Lower  Level  Processes--Medium.  Many  have  been 
eliminated. 

Cognitive  Processes--Poor.  Some  shunting  to 
visible  files  still  occurs  and  transition 
between  operations  not  identifiable. 

ERROR  RATES: 

Lower  Level  Processes--Meoium.  Many  have  been 
el iminated. 

Cognitive  Processes— Medium.  All  shunting 
except  to  visible  fMes  has  been  eliminated. 

ACCESSION  FREQUENCY: 

Medium.  Data  accession  to  visible  files  is 
now  measurable. 

INPUT  VARIABLE  CONTROL:  Good  (-}.  Only  visible  file  shunting  remains 
uncontrolled. 

COST: 

PERSONNEL:  Medium.  Non-vi sible  files  can  be 
automated. 

HARDWARE/ SOFTWARE:  Medium.  Non-visible  files  are 
automated. 
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TABLE  5*4.  EVALUATION  OF  CONFIGURATION  D 

CONFIGURATION:  D 

SYSTEM  EMULATED:  Manual 

PLAYER  PERFORMED  EOs.  All  except  RECEIVE  and  TRANSMIT 

(VOICE),  NON-VISIbLE  FILES,  and 

DISPLAYS 

REALISM:  Poor.  So  little  of  staff  complement  is  present. 

MEASUREMENT  OF: 


PROCESS  TIMES: 

Lower  Level  Processes--Poor.  Very  few 
performed! 

Cor.gitive  processes--Poor.  Transitions  between 
operations  not  identifiable. 

ERROR  RATES: 

Lower  Level  P? ocesses--Poor  Very  few  per- 
f  armed . 

Cognitive  Processes— Good.  All  shunting  is 
eliminated;  data  used  for  decision  making  are 
identifiable. 

ACCESSION  FREQUENCY : 

Good. 

INPUT  VARIABLE  CONTROL:  Good. 

COST: 


PERSONNEL:  Medium. 
HARDWARE/ SOFTWARE:  Hig,.. 
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TABLE  5-5.  EVALUATION  OF  CONFIGURATION  E 


CONFIGURATION;  E 

SYSTEM  EMULATED:  Manual 

PLAYER  PERFORMED  EOs:  Cognitive  only 
REALISM:  Poor. 

MEASUREMENT  OF: 

PROCESS  TIMES: 

Lower  Level  Processes— Poor.  None  performed. 

Cognitive  Processes--Poor.  Transitions 
between  operations  not  identifiable. 

ERROR  RATES: 

Lower  Level  Processes--Poor.  None  performed. 
Cognitive  Processes— Good . 

ACCESSION  FREQUENCY: 

Good. 

INPUT  VARIABLE  CONTROL:  Good. 

COST: 

PERSONNEL:  Low. 

HARDWARE/ SOFTWARE:  High. 
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TABLE  5-6.  EVALUATION  OF  CONFIGURATION  F 


CONFIGURATION:  F 

SYSTEM  EMULATED:  ADP-Assisted 

PLAYER  PERFORMED  EOs:  All  not  automated  in  field 

REALISM:  Excellent 

MEASUREMENT  OF: 

PROCESS  TIMES: 

Lower  Level  Processes— Good . 

Coanitive  Processes— Good.  Transitions 
between  operations  are  measurable  at 
terminal . 

ERROR  RATES: 

Lower  Level  Processes— Good . 

Cognitive  Processes— Good . 

ACCESSION  FREQUENCY: 

Good. 

INPUT  VARIABLE  CONTROL:  Good. 

COST: 

PERSONNEL:  Low. 

HARDWARE/ SOFTWARE :  High. 
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TABLE  5-7.  EVALUATION  OF  CONFIGURATION  E1 

CONFIGURATION:  E1 

SYSTEM  EMULATED:  ADP-Assisted 

PLAYER  PERFORMED  EOs:  Cognitive  only 
REALISM:  Poor.  But  substantially  better  than  Configuration  E. 

MEASUREMENT  OF: 

PROCESS  TIMES: 

lower  Level  Processes— Poor •  None  performed. 
Cognitive  Processes— Good . 

ERROR  RATES: 

i  Ann»r  level  Processes-Poor.  None  performed. 
Cognitive  Processes— Good . 

INPUT  VARIABLE  CONTROL:  Good. 

COST: 

PERSONNEL:  Low. 

HARDWARE/SOFTWARE:  High. 
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measure  the  amount  of  time  each  action  spends 
in  queue  awaiting  the  next  elementary  opera¬ 
tion.  This  evaluation  is  further  divided  . 
between  the  ability  to  measure  process  times 
for  lower  level  processes  and  cognitive  pro¬ 
cesses.  To  continue  the  example  used  above, 
Configuration  A  (Table  5-1)  is  rated  "Good" 
for  lower  level  processes,  but  Configuration 
E  (Table  5-5)  is  rated  "Poor"  because  none 
are  being  performed.  On  the  other  hand  both 
configurations  are  rated  "Poor"  for  measuring 
cognitive  processes  because  the  transition 
between  cognitive  processes  is  not  detectible 
in  the  manual  mode. 

-  ERROR  RATES,  in  particular,  for  data  errors  and 
procedure  errors.  (As  has  already  been  re¬ 
iterated  in  para  3.3,  cognition  errors  are  not 
detectible  within  the  information  system.) 

This  quality  is  also  evaluated  separately  fo** 
lower  level  processes  and  cognition  processes. 

The  capability  to  measure  errors  is  directly 
dependent  on  the  presence  of  hard  copy  in  the 
data  stream.  If  no  hard  copy  of  an  action  is 
produced,  error  detection  becomes  extremely 
difficult.  By  the  same  token  when  hard  copy 

is  not  the  basis  for  cognitive  processes  it 
becomes  difficult,  if  not  impossible,  to  distin¬ 
guish  between  data  and  cognition  errors. 

-  ACCESSION  FREQUENCY.  This  quality  refers  to 
the  capability  to  determine  the  data  elements 
retrieved  by  the  decision  maker  from  the  data 
base  in  order  to  perform  the  cognitive  processes. 
To  the  extent  lata  elements  are  shunted  into 

the  decision  maker's  memory  as  a  result  of  per¬ 
forming  or  exposure  to  lower  level  processes, 
accession  frequency  becomes  impossible  to  mea¬ 
sure. 

•  INPUT  VARIABLE  CONTROL.  This  attribute  refers  to 
the  experimenter's  capability  to  control  such 
variables  as:  the  amount  and  kind  of  information 
provided,  time  constraints  imposed  on  decision 
.making,  and  the  quality  of  the  information  pro¬ 
vided  (in  terms  of  errors,  omissions,  and  delays 
between  event  and  report).  It  also  includes  the 
objectivity  with  which  player  decisions  are 
entered  in  the  battle  outcome  generator  and  the 
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strict  adherence  of  controllers  to  experimental 
objectives.  Two  factors  can  militate  against 
such  control.  One  is  the  factorial  explosion  of 
controllers  required  for  voice  communication  with 
the  staff  module.  The  other  is  the  absence  of 
control  over  the  data  flow  within  a  fully  populated 
staff  module  operating  in  the  manual  mode.  These 
two  factors  combine  to  make  it  virtually  impossible 
to  run  very  many  kinds  of  experiments  with  a  fully 
manned  module  in  the  manual  mode  using  voice 
communication.  The  degree  of  control  clearly 
increases  the  more  lower  level  processes  are 
precluded. 

•  COST.  This  factor  is  evaluated  in  terms  of  the 
numbers  of  player  personnel  required  and  the 
estimated  hardware/software  costs.  Tables  5-1 
through  5-7  indicate  that  the  number  of  personnel 
is  reduced  as  lower  level  processes  are  removed 
from  module.  This,  of  course,  assumes  that  ADP 
is  replacing  human  processing  whether  this  takes 
place  inside  or  outside  the  module  (ADP  assistance 
to  the  control  element).  If,  in  the  manual  mode, 
lower  level  processes  are  simply  shifted  from  the 
players  to  the  controllers,  there  is  no  correspond¬ 
ing  reduction  in  personnel.  By  the  same  token,  to 
the  extent  that  ADP  reolaces  lower  level  processing 
(whether  in  the  module  or  in  the  simulation), 
hardware/software  costs  increase. 


5.2.1  Summan 


Table  5-8  summarizes  the  results  of  the  foregoing  trade-off 
analysis.  A  number  of  implications  of  this  analysis  are  immediately 
apparent: 


t  The  cognition  processes  can  be  adequately  measured 
and  controlled  only  in  the  ADP-assisted  mode 
(Configurations  F  and  E^). 

t  Configuration  8  is  best  for  studying  the  lower 
level  processes  except,  of  course,  receive  and 
transmit. 


•  Configuration  F  is  best  for  studying  ADP-assisted 
systems  because  there  are  no  advantages,  but 
several  ii sadvantages ,  in  going  to  Configuration  E' . 
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5.2.2  Examples. 


Before  dismissing  configurations  other  than  B  and  F  as  purely 
arbitrary  constructs  with  little  practical  application  it  is  useful 
to  look  at  some  examples  of  other  configurations  that  have,  in  fact, 
been  applied  for  various  applications  in  the  past.  This  sets  the 
stage  for  the  notion  that  there  may  be  more  subtle  reasons  for  using 
some  of  the  other  configurations  for  specific  applications.  That 
notion  is  developed  in  para  5.4  below. 

5. 2. 2.1  Configuration  A. 

This  configuration  is  the  one  most  often  used  for  training 
staffs  and  staff  sections  in  actual  military  organizations.  It  was 
also  the  configuration  used  to  measure  the  performance  of  division 
staff  sections  in  a  series  of  workshops  conducted  at  Ft  Hood,  Texas, 
in  1974^.  Since  a  principal  purpose  of  that  series  of  tests  was  the 
determination  of  the  actual  information  flow  in  a  fully  manned  staff 
section  operating  in  the  manual  mode,  this  configuration  appeared  to 
be  the  only  reasonable  choice.  It  was  during  that  series  of  tests 
that  the  authors  first  observed  the  shunting  phenomenon  and  its  effect 
on  information  routing  and  processing. 

5. 2. 2. 2  Configuration  E. 

It  is  pertinent  to  cite  two  examples  of  the  employment  of 
this  configuration  for  completely  diverse  purposes: 

•  Classroom  Application.  Already  mentioned  in  para 

5.1.2  is  the  classroom  application  at  military 
schools  such  as  the  Command  and  General  Staff 
School.  The  purpose  of  this  application  is  to 
provide  instruction  in  techniques  useful  for  the 
cognitive  processes  involved  in  situation  recogni¬ 
tion  and  action  selection.  Except  for  very 
limited  student  participation  in  the  file,  post/ 
plot,  coordinate,  external  routing,  and  compose 
processes,  all  lower  level  pre-processing  is 
carried  out  well  in  advance  by  the  faculty  and 
thoroughly  reviewed  to  eliminate  errors  and 
ambiguities  that  might  interfere  with  the  instruc¬ 
tion.  Clearly  this  procedure  is  not  readily 
adaptable  to  on-line  operation.  In  fact,  one  of 
the  shortcomings  of  this  mode  of  operation  is 
that  for  a  continuing  scenario  the  data  bose  must 


3  Tiede,  R.  V.,  Walker,  M.  E.,  Stenstrom,  D.  J.  and  Sweeny,  S.  D. , 

The  Integrated  Battlefield  Control  System  ( I BCS )  Third  Refinement 
Final  Report,  Science  Appl  icTtlons,  Inc. ,  McLean,  VA,  31  .March  1975 . 
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be  continually  purged  to  eliminate  the  student's 
contribution  to  earlier  phases  (unless  it  just 
happened  to  coincide*with  the  "school  solution"). 

Hence,  the  student  never  finds  out  what  would  have 
been  the  result  of  implementing  his  own  solution. 

•  SIMTQS^.  For  this  application  Configuration  E  was 
chosen  in  order  to  study  the  decision  making  process 
itself.  As  in  the  case  of  the  classroom  application, 
a  data  base  was  created  in  advance  and  it  was  acces¬ 
sible  by  the  decision  maker  either  on  demand  or 
automatically.  There  was,  of  course,  no  dynamic 
interaction  between  decision  maker  outputs  and  a 
continuing  scenario. 

5.3  IMPACT  OF  COMMUNICATION  MEDIA 

Since  the  various  configurations  described  above  drastically 
change  the  mix  of  communication  media  employed  to  transmit  data  both 
to  and  from  the  decision  maker,  it  is  worthwhile  to  examine  the 
controllability  and  measurability  constraints  imposed  by  each.  In 
this  discussion  it  is  assumed  that  the  data  reduction  problem  inherent 
in  audio/visual  recording  precludes  use  of  this  technique  for  data 
collection  in  any  practical  sense.  It  also  assumes  that  burdening 
the  subject/players  with  any  significant  degree  of  data  collection 
would  defeat  the  purpose  of  the  experiment.  It  should  also  be  noted 
that  the  constraints  attributed  to  each  of  the  communication  media 
treated  below  apply  if  that  communi cation  medium  alone  is  being 
utilized.  The  constraints  resulting  from  combinations  of  media  are 
treated  Jn  para  5.4  below.  The  discussion  in  the  following  subpara¬ 
graphs  treats  the  following  characteristics  of  the  nedia: 

•  Is  access  to  the  data  base  by  the  decision  maker 
controlled  and  measurable? 

•  Is  the  duration  of  the  decision  maker's  access 
measurable? 

•  Are  errors  in  the  data  flow  measurable? 

•  Is  shunting  inherently  associated  with  the  medium? 


Levit,  Heaton,  and  Alden,  Development  ano  Application  of 
Decision  Aids  for  Tactical  ^Control  oTjmTeTi eld  Operations, 
Honeywell  Systems'  and  Research  Center,  Minneapolis,  MN , 
December  1977. 
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5.3.1  Voice  Communication, 

To  the  extent  that  data  base  information  is  transmitted  within 
the  staff  module  by  means  of  voice  communication,  the  decision  maker 
can  neither  be  denied  access  to  it  nor  can  his  access  be  readily  mea¬ 
sured  in  terms  of  duration  of  access  or  errors  in  transmission.  This 
is  at  the  very  heart  of  the  shunting  phenomenon  which  short-circuits 
the  formal  information  flow  path  and  tends  to  make  the  data  base  an 
entity  which  is  shared  in  the  memories  of  all  members  of  the  staff 
team,  but  especially  the  decision  makers.  It  is  this  phenomenon 
that  makes  the  all-manual  staff  module  (Configuration  A)  so  difficult 
to  analyze.  However,  any  effort  to  control  the  "Chatter"  which  is 
such  an  integral  part  of  manual  processing  and  to  substitute  written 
messages  for  all  intra-module  communication  seriously  distorts  normal 
staff  behavior.  Configuration  B  is  probably  the  best  compromise  for 
studying  the  lower  level  processes  because  it  does  impose  significant 
constraints  on  the  information  input  to  the  module  without  affecting 
unduly  the  lower  level  processes  other  than  "receive"  and  "transmit." 

5.3.2  Written  Messages. 

To  the  extent  that  written  messages  can  be  substituted  for 
all  intra-module  communication,  all  of  the  difficulties  of  control  and 
measurement  associated  with  voice  communication  are  overcome.  Clearly, 
this  communication  mode  automatically  constrains  access  to  the  data 
base.  The  exchange  of  written  messages  provides  an  easily  observable 
physical  act  which  facilitiates  measurement  of  process  times.  The 
written  message  also  provides  "ground  truth"  which  facilitates  detec¬ 
tion  of  data  errors  and  also  provides  a  basis  for  detecting  procedural 
errors  (faulty  routing,  etc.).  The  difficulty  with  using  written 
message  exchange  for  all  data  transfers  when  studying  the  manual  staff 
processes  is  that  insistence  on  this  communication  means  distorts  some 
of  the  manual  processes,  e.g.,  retrieve,  especially  from  maps  and 
displays. 

5.3.3  Terr.por>>ry  Displays. 

Although  only  a  limited  class  of  data  exchanges  within  the 
manual  staff  module  employ  temporary  displays  (sitmaps,  tote  boards, 
etc.),  this  form  of  communication  is  extremely  important.  Displays 
are  readily  accessible  sets  of  data  that  provide  the  most  convenient 
and  frequently  used  “buffers"  for  human  memory.  This  very  convenience, 
i.e.,  so  little  effort  is  required  to  effect  a  data  transfer,  also 
makes  this  medium  share  the  properties  of  voice  communication.  Since 
displays  ore  posted  for  maximum  visibility  by  decision  makers,  it  is 
not,  in  general,  possible  to  control  or  record  the  decision  maker's 
access  to  such  data.  Because  they  are  temporary  (usually  grease  pencil 
on  acetate  to  facilitate  update)  there  is  no  permanent  record  which 
would  provide  means  for  error  detection.  Finally,  because  of  the  ease 
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of  access,  displays  give  rise  to  the  shunting  phenomenon  in  the  same 
way  as  voice  communication. 


5.3.4 


This  medium  of  exchange  shares  all  of  the  properties  of 
temporary  displays  except  that  a  permanent  record  of  the  data  trans¬ 
mitted  is  available.  This  property  permits  detection  of  data  errors. 


5.3.5  ADP  Display 


The  interposition  of  a  computer  terminal  between  the  decision 
maker  and  the  data  base  immediately  overcomes  the  control  and  measur¬ 
ability  deficiencies  of  displays.  Not  only  can  access  be  controlled, 
but  a  record  can  be  kept  of  every  transaction  to  include  the  duration 
of  access.  A  permanent  record  of  every  transaction  can  be  kept  for 
error  detection.  The  shunting  phenomenon  can  be  completely  eliminated 
if  the  terminal  is  the  only  interface  between  the  decision  maker  and 
the  information  system. 


5.3.6  ADP  Hard  Copy. 

The  generation  of  hard  copy  by  computer  to  substitute  for 
written  messages  does  not  change  any*  of  the  attributes  of  the  written 
word  insofar  as  control  and  measurement  are  concerned. 


5.3.7  Summary. 

The  results  of  the  above  discussion  of  the  impact  of  communi¬ 
cation  media  on  control  and  measurement  are  summarized  in  Table  5.9. 
The  following  conclusions  are  readily  apparent: 


•  Because  of  the  non-directional  nature  or  data 
propagation  by  means  of  voice  communication  and 
displays,  employment  of  these  media  is  not  amenable 
to  control  of  access  to  the  dat3  base  or  to  detec¬ 
tion  and  measurement  of  access  time.  Similarly, 
because  there  is  no  permanent  record  of  voice  or 
temporary  display  transactions  they  are  not  amena¬ 
ble  to  data  or  procedural  error  detection.  These 
same  properties  encourage  the  shunting  phenomenon 
and  make  it  virtually  impossible  to  preclude  it. 


•  Permanent  displays  share  all  of  the  above  properties 
except  that  the  permanent  record  does  permit  detec¬ 
tion  of  errors. 


•  In  contrast,  written  messages  and  computer  displays 
and  hard  copy  can  be  readily  directed  to  designated 
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TA3LE  5-9.  IMPACT  OF  COMMUNICATION  MEDIA  ON  MEASUREMENT  AND  CONTROL 
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addressees  and  the  accessing  of  data  becomes  a 
detectible  and  measurable  property. 

5.4  FACTORS  AFFECTING  TASK  ASSIGNMENT 

It  is  reasonably  clear  that  the  assignment  of  tasks  to  indi¬ 
vidual  players  will  be  determined  by: 

•  The  purpose  of  the  investigation. 

•  The  available  labortory  tool  (s)~i  .e. ,  models  and 
simulations. 

•  The  staff  system  being  emulated  (manual,  ADP- 
assisted,  etc.). 

Of  these,  the  purpose  of  the  investigation  is  clearly  the  driver  or 
objective  function  and  the  last  two  serve  as  constraints.  The  dis¬ 
cussion  thus  far  in  this  section  has  largely  been  devoted  to  estab¬ 
lishing  a  framework  for  examining  the  constraints  imposed  by  the 
configuration  of  the  simulation  and  the  system  being  emulated.  We 
shall  now  examine  how  experimental  purpose  affects  task  assignment 
and  how  such  assignments  may  be  constrained  by  considerations  of  tool 
and  system. 

5.4.1  Purpose  of  the  Experiment. 

We  need  first  to  consider  a  reasonably  comprehensive  classifi¬ 
cation  of  experimental  purposes  for  which  a  model  or  simulation  of  thi 
type  might  be  used.  Since  we  are  talking  about  a  combat  simulation  at 
the  combined  arms  level  in  which  are  embedded  one  or  more  live  staff 
modules  which  will  be  the  subjects  of  the  experiment,  we  are  really 
talking  about  experiemnts  which  will  examine  the  functioning  of  the 
military  staff  and  how  this  affects  the  military  decision  making  pro¬ 
cess.  Since  the  purpose  of  the  staff  is  to  facilitate  human  decision 
making  (para  5.1.1),  one  can  say  that  the  experimental  purpose  of  such 
a  tool,  for  behavioral  research,  is  to  examine  the  effectiveness  of 
decision  making  as  a  function  of  a  number  of  discrete  independent  vari 
ables.  The  following  list  is  sufficiently  comprehensive  for  our  pur¬ 
pose  since  it  seems  to  provide  a  category  for  all  of  the  experiments 
that  have  been  suggested.  The  purpose  of  such  a  tool  is  to  examine 
decision  making  performance  as  a  function  of: 

t  The  kind  of  data  accessed. 

•  *..e  quality  of  the  data  accessed. 

•  The  performance  of  the  individual  processes. 


t  The  data  transfer  medium. 

•  The  time  available  for  decision  making. 

•  The  personality  of  the  decision  maker. 

Experiments  involving  the  first  five  of  these  independent  variables 
are  examining  the  effect  of  changes  in  information  system  external  to 
the  decision  maker  on  his  decision  making.  The  last  turns  the  focus 
back  onto  the  decision  maker  to  see  how  decision  making  is  affected 
by  changes  In  the  personality  making  the  decision.  In  order  to  address 
the  question  of  task  assignment  in  experiments  of  these  various  types 
we  need  to  examine  each  of  these  variables  in  greater  detail  to  see 
exactly  what  kinds  of  experiments  might  be  conducted. 

5.4.2  Kinds  of  Behavioral  Science  Experiments. 

The  general  classes  of  behavioral  science  experiments  using 
a  battle  simulation  may  be  further  expanded  as  follows: 

5.4. 2.1  Data  Requirement  and  Classification  Experiments.  (Investi¬ 
gations  of  the  pertinence  of  information  provided  to  and  accessed  by 
the  decision  maker(s).) 

Such  experiments  seek  to  relate  the  effectiveness  of  the 
cognitive  processes  (as  reflected  in  the  simulated  combat  outcomes) 
with  the  substance  of  the  information  provided  the  decision  maker. 

These  experiments  would  include  the  following  various  conditions: 

-  All  of  the  data  normally  generated  by  a  combat 
environment  are  accessible  (free  access). 

-  The  data  normally  generated  are  selectively  denied 
(selected  access). 

-  Since  data  are  usually  presented,  not  as  individual 
data  elements,  but  as  dat3  sets  combining  several 
data  elements,  the  combination  of  data  elements 
comprising  a  single  data  package  can  also  be  varied 
(data  packaging). 

5. 4. 2. 2  Data  Quality  Experiments. 

Such  experiments  seek  to  relate  the  effectiveness  of  the 
cognitive  processes  (as  reflected  in  the  simulated  combat  outcomes) 
to  the  quality  of  the  data  accessed  by  the  decision  maker.  These 
experiments  would  include  controiloc  changes  in  the  following: 
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-  Timeliness  of  the  aata  provided  (cognition/ 
timeliness). 

-  Errors  in  the  data  provided  (cognition/accuracy). 

-  Completeness  of  the  data  provided  (cognition/ 
completeness). 

-  False  data  provided  (ccgni tion/truth). 

5. 4. 2. 3  Proces.  Performance  Experiments. 

These  experiments  measure  human  performance  parameters  for 
each  of  the  elementary  operations  defined  in  para  3.1.1.  Decause  of 
their  differing  effect  on  task  assignment,  one  has  to  distinguish 
between  such  experiments  for  measuring  lower  level  processes  and  those 
for  the  purpose  of  measuring  cognitive  processes.  One  can  thus  dis¬ 
tinguish  between  experiments  designed  to  measure. 

-  Processing  times  and  delays  in  carrying  out  lower 
level  processes  (process/delay). 

-  Errors,  both  data  and  processing,  in  carrying  out 
lower  level  processes  (process/error) . 

-  Omissions  in  carrying  out  lower  level  processes 
(process/omissions). 

-  Sequence  of  carrying  out  lower  level  processes 
(process/sequence) . 

-  Processing  times  and  delays  in  carrying  out  cognitive 
processes  (cogni tion/delay) . 

-  Errors  in  carrying  out  cognitive  processes  (cognition/ 
errors) . 

-  Omissions  in  car»%yin^  out  cognitive  processes 
(cogni  t  ion/omission  ;>  5. 

5. 4. 2. 4  Data  Tranrfer  Experiments. 

These  experiments  seek,  to  establish  the  relation  between 
the  nature  of  the  data  transfer  medium  between  the  decision  maker  ind 
the  data  ba^j  and  the  effectiveness  of  his  cognitive  process  as 
measured  by  the  outcomes  of  simulated  combat.  They  can  also  seek  to 
relate  the  transfer  medium  to  the  performance  parameters  of  the  cogni¬ 
tive  processes.  Such  experiments  are  of  two  types: 


-  Media  that  prevent  shunting  (controlled  transfer). 

-  Media  that  permit  shunting  (shunting  transfer). 

5.4. 2. 5  Constrained  Time  Experiments. 

Such  experiments  seek  to  observe  the  changes  in  process  per¬ 
formance  and/or  combat  outcome  as  a  function  of  the  time  available 
for  decision  making.  This  is  the  most  common  means  of  imposing  strc:s 
on  decision  makers  and  information  processors. 

5. 4. 2. 6  Personality  Experiments. 

Such  experiments  could  seek  to  observe  changes  in  process  and 
cognition  performance  as  well  as  combat  outcomes  as  a  result  of  chang¬ 
ing  the  staff  persons  to  reflect  controlled  changes  in  intelligence, 
background,  experience,  personality,  etc. 

5.4.3  Experiments  and  Variab.es. 

5. 4. 3.1  Reclassification. 

Before  proceeding  to  the  next  development,  it  is  important  to 
note  that  the  classification  of  experiments  listed  above  is  somewhat 
redundant  from  the  point  of  view  of  identifying  task  design  require¬ 
ments.  For  example,  data  requirements,  data  organization,  and  controlled 
transfer  medium  experiments  all  impose  the  same  requirements  on  those 
variables  affected  by  configuration  and  task  design  and  none  can  be 
performed  in  any  configuration  that  permits  shunting.  Let  us,  therefore, 
redefine  four  classes  of  experiment  that  encompass  all  nine  of  the  classes 
listed  above.  These  are: 

•  Data  Accession  Experiments.  This  class  includes 
requi remen t s ,  efr fa  organization,  and  controlled 
transfer  experiments. 

•  Lower  Level  Process  Experiments.  This  includes 
process  experiments  as  described  in  para  5.4.2. 3 
as  well  as  those  time  constrained  and  personnel 
experiments  whose  purpose  is  to  measure  lower 
level  process  performance  as  3  result  of  change^ 
in  those  independent  variable?. 

•  Cognition  Experiments.  This  class  includes  the 
classes  previously  TTenti f led  as  cognition  per¬ 
formance,  data  quality,  as  well  as  those  time 
constrained  and  personality  experiments  whose 
purpose  is  measurement  of  effect  on  cognition 
(and  battle  outcome). 
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•  Shunting  Transfer  Experiments.  Th-»s  is  the  only 
one  of  the  original  nine  classes  that  remains 
unique  in  that  it  amounts  to  an  effort  to  study 
cognition  processes  utilizing  the  nanua1  mene  data 
transfer  media  that  permit  shunting.  It,  therefore, 
precludes  utilizing  Configurations  E,  F,  and  E1. 

5.4. 3. 2  Variables. 

The  next  step  in  the  development  of  principles  of  task  assign¬ 
ment  is  to  examine  the  various  kinds  of  experiments  described  above 
in  terms  of  the  variables  that  can  be  manipulated  or  measured  nt  this 
kind  of  combat  simulation.  Such  an  examination  can  be  made  with  the 
aid  of  the  matrix  shown  at  Table  5-10.  Listed  as  column  headings  in 
the  matrix  are  the  manipulable  and  measurable  variables.  These  are 
subdivided  into  those  variables  which  should  be  completely  determined 
by  the  experimental  design  and  those  which  are  determined  by  the  com¬ 
bination  of  configuration  selected  and  the  task  assignment.  Listed 
as  row  headings  on  the  left  are  the  classes  of  experiments  identified 
in  para  5.4.2.  The  entries  in  the  matrix  indicate  whether  the  vari¬ 
able  in  question  is  a  potential  independent  variable  (I),  a  variable 
that  must  be  controlled  (C),  or  a  potential  and  measurable  dependent 
variable  (D),  i.e.,  output.  The  word  "potential"  is  used  in  the  pre¬ 
ceding  sentence  to  indicate  that  *11  possible  independent  and  depen¬ 
dent  variable:  have  been  identified.  They  would  not,  in  general,  all 
be  used  in  the  same  experiment.  For  example,  the  four  basic  charac¬ 
teristics  of  the  input  data  would  not  all  be  varied  simultaneously  for 
data  quality  experiments.  Similarly,  for  process  performance  experi¬ 
ments,  _ne  might  not  need  to  measure  all  of  the  process,  cognition 
and  combat  output  variables  potentially  available  as  outputs. 

In  addition  tc  these  entries  the  entry  "NA"  appears  in  a  few 
cases  where  tne  variable  is  inappropriate.  For  example,  in  experi¬ 
ments  which  try  to  measure  the  cognition  processes  it  is  clearly  not 
possible  to  utilize  shunting  transfers  of  data  between  the  information 
system  and  the  decision  maker.  Similarly,  for  experiments  which  do 
invoke  fhe  shunting  phenomenon,  controlled  transfer  is  clearly  inap¬ 
propriate.  The  footnotes  a' so  specify  output  measurements  which  are 
precluded  when  shunting  data  transfers  are  permitted. 

5.4.4  Task  Design  requirements 

The  analysis  has  now  reached  the  point  where  we  can  identify, 
for  all  possible  combinations  of  configuration  and  class  of  experiment, 
which  variables  require  modification  of  the  SOP  task  description.  This 
may  be  needed  either  for  the  purpose  of  controlling  the  variable  or 
for  measuring  its  value  if  it  is  needed  as  an  output.  The  next  series 
of  tables  identify  such  variables  for  each  of  the  four  classes  of  ex¬ 
periments  defined  above. 
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5.4.4. 1  Data  Accession  Experiments. 

Table  5-11  shows  the  results  of  examining  each  configuration 
that  can  be  used  for  this  class  of  experiment  to  determine  which  variables 
(of  those  affected  by  configuration  and  task  design)  need  to  be  addi¬ 
tionally  constrained  by  means  of  the  task  design.  Listed  across  the 
top  are  the  nine  variables  affected  by  configuration  choice  and  task 
design.  These  are  further  identified  as  to  whether  they  are  variables 
to  be  controlled  in  this  class  of  experiment  or  whether  they  are 
potential  output  variables  to  be  measured.  Shown  as  row  headings  at 
the  left  are  the  seven  configurations  previously  defined.  Entries 
for  the  first  four  of  the  configurations  (A  through  D)  are  blank  since 
these  are  the  configurations  which  permit  shunting  and  are,  therefore, 
unusable  for  measuring  data  access.  The  table  indicates  that  for 
configurations  E  and  E^  (all  lower  level  processing  within  the  simula¬ 
tion  and  the  decision  maker  presumably  communicates  with  the  data  base 
through  a  terminal)  the  simulation  itself  imposes  all  of  the  needed 
constraints  on  the  controlled  variables  and  provides  the  means  neces¬ 
sary  for  all  required  measurements.  Configuration  F  (ADP-assisted 
but  with  some  manual  lower  level  processing) ,  on  the  other  hand,  does 
require  additional  constraints  on  the  lower  level  processing  variables. 
The  simulation  clearly  provides  the  needed  control  on  those  lower  level 
processes  which  are  automated,  but  such  controls  are  not  present  wherever 
there  is  a  person-to-person  data  transfer.  For  such  transfers  the  SOP 
task  description  must  be  augmented  to  provide  for: 

•  Recording  the  time  of  receipt  of  the  action  and  time 
of  initiation  of  processing  (to  account  for  both 
time  spent  in  queue  and  in  process). 

•  Retaining  a  hard  copy  of  the  data  in  order  to  control 
error  rates  and  omissions. 

•  Identifying  the  person  handling  the  transaction  in 
order  to  determine  the  sequence  used  in  processing. 

Furthermore,  to  insure  that  such  lower  level  processing  as  is  still 
carried  out  by  people  does  not  unduly  degrade  the  data  input,  such 
persons  should  meet  minimum  performance  standards  (P.  Std.)  for  process 
time,  error  rate,  rate  of  omissions,  and  rate  of  making  mistakes  in 
sequencing  (procedure).  On  the  other  hand,  since  the  decision  maker 
is  presumably  accessing  the  data  base  solely  through  a  computer  ter¬ 
minal,  all  of  his  cognition  variables  are  directly  measurable  by  the 
simulation  and  no  additional  task  assignments  over  those  required  by 
the  operating  SOP  need  be  imposed. 
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TABLE  5rl1.  CONFIGURATION  TASK  ASSIGNMENTS  FOR  DATA  ACCESSION  EXPERIMENTS 
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5. 4. 4. 2  Lower  Level  Process  Experiments. 

Table  5-12  shows  the  results  of  a  similar  analysis  of  the 
lower  level  process  experiments.  For  such  applications  Configurations 
E  and  E*  are  inapplicable  by  definition  since  they  provide  that  all 
lower  level  processing  be  done  within  the  simulation  and  not  by  the 
populated  module.  Configuration  A  provides  that  all  processing  be 
done  manually  so  the  simulation  in  itself  provides  no  controls  on  any 
of  these  variables  except  that  it  does  provide  combat  outcomes  with  no 
modification  of  the  SOP  task  assignments.  On  the  other  hand,  the  task 
assignment  must  again  provide  for  means  to  measure  process  timing, 
error  rates,  omissions,  and  sequence  as  in  the  case  of  the  data  accession 
experiments.  For  this  class  of  experiments,  these  variables  are  to  be 
measured  and,  therefore,  no  performance  standard  need  be  imposed;  the 
purpose  is  to  measure,  not  control,  human  performance.  None  of  the 
cognition  variables  or  frequency  of  data  accession  can  be  measured  in 
this  configuration  for  reasons  explored  at  length  in  para  5.2.  Combat 
outcome  is,  of  course,  measurable  by  the  simulation  itself. 

Configurations  B,  C,  and  D  are  similar  in  that  they  progres¬ 
sively  eliminate  more  and  more  manual  processes  from  the  populated 
module  and  move  them  "behind  the  curtain"  into  the  simulation.  The 
simulation  itself  can  now  provide  the  means  to  measure  human  performance 
at  the  interface  between  the  simulation  and  man,  but  for  the  man-to¬ 
man  exchanges  the  task  assignment  must  still  include  means  for  measur¬ 
ing  receipt  and  initiation  times,  for  retaining  hard  copy,  and  for 
identifying  operators.  The  other  difference  between  these  configura¬ 
tions  and  Configuration  A  is  that  these  configurations  permit  measure¬ 
ment  of  cognition  errors  and  omissions  (should  that  be  desired)  by 
modifying  the  task  assignment  to  insure  that  all  displays  are  made  on 
permanent  copy. 

The  same  considerations  also  apply  tc  the  first  four  process 
variables  in  Configuration  F  assuming  that  the  manual  processing  in 
the  system  being  emulated  includes  at  least  some  man-to-man  exchanges. 
Since  the  decision  maker's  interface  with  the  simulation  is  presumably 
a  computer  terminal,  the  simulation  take  care  of  cognition  performance 
measurements. 

5.4.4. 3  Cognition  Experiments. 

This  class  of  experiments  can  conceivably  be  conducted  with 
all  seven  configurations,  although  in  the  case  of  Configuration  A  the 
only  cognition  measurement  possible  is  combat  outcome.  This  is  dis¬ 
played  in  Table  5-13.  For  these  experiments,  the  lower  level  processes 
need  to  be  controlled  in  order  to  insure  a  reasonably  standard  quality 
data  base  as  a  basis  for  the  cognition  measurements.  Therefore,  the 
task  assignments  for  Configurations  A  through  D  must  proviae  for  means 
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TABLE  5-13,  CONFIGURATION  TASK  ASSIGNMENTS  FOR  COGNITION  EXPERIMENTS 


t 


3WODinO 

IVGhOO 

a 

u 

3 

V 

«3 

0) 

3! 

SIM 

SIM 

SIM 

SIM 

I 

SIM 

SIM 

SIM 

COGNITION 

SN0ISSIW0 

0) 

S- 

3 

W 

to 

Q) 

X 

f 

TA 

TA 

TA 

SIM 

SIM 

SIM 

31VH 

mm 

0) 

u 

3 

CO 

*0 

<y 

X 

NA 

TA 

TA 

TA 

SIM 

SIM 

SIM 

AVT3G 

0) 

&. 

NA 

* 

NA 

NA 

SIM 

SIM 

SIM 

PROCESS 

A3N3d()3ad 

N0ISS333V 

a> 

0. 

3 

w> 

«tJ 

0) 

X 

c 

sc 

5 

NA 

NA 

SIM 

SIM 

SIM 

33N3flt)3S 

r— 

O 

&. 

4.J 

C 

o 

o 

TA 

P. STD. 

SIM 

TA 

P.STD. 

SIM 

TA 

P.STD. 

d 

i— 

X  oo 
*— «  * 
OOh-a. 

SIM 

d 

X  oo 
oo  ?  a.* 

SIM 

SNOISSIWO 

o 

•*-> 

c 

o 

o 

TA 

P.STD. 

SIM 

TA 

P.STD. 

— 

d 

H- 

X  oo 

■ 1  <c  • 

00  H-  CL 

d 

h- 

X  <o 

— •  <  • 
OO  ♦—  Cl. 

SIM 

d 

►— 

X  00 
►-*  «*C  • 

OO  ►-  G. 

SIM 

iiva 

aoaw 

o 

u 

4-» 

c 

o 

o 

TA 

P.STD. 

SIM 

TA 

P.STD. 

SIM 

TA 

P.STD. 

SIM 

TA 

P.STD. 

SIM 

3 

NIS 

AVT3  a 

c 

u 

■*--» 

c 

a 

<~> 

TA 

P.STD. 

SIM 

TA 

P.STD. 

SIM 

TA 

P.STD. 

d 

f— 

X  oo 

•-* c  . 
oo  >—  a. 

— 

X 

v> 

— 

d 

h* 

*-*  <  • 
</>  v—  a. 

SIM 

CONFIGURATION 

< 

0 

| 

o 

ui 

u. 

U4 

5-31 


of  timing  lower  level  operations,  hard  copy  as  a  standard  of  comparison, 
and  identification  of  individuals  to  insure  proper  assignment  of  tasks. 
This  provides  the  means  to  insure  that  specified  standards  of  perfor¬ 
mance  in  carrying  out  lower  level  processes  have  been  achieved.  Specify¬ 
ing  minimum  performance  standards  for  these  lower  level  processes  will 
also  assist  in  achieving  a  standard  data  base.  For  Configurations  B 
through  C  the  simulation  will  impose  the  needed  control  for  those 
processes  moved  back  into  the  simulation.  It  will  also  be  noted  that, 
for  these  three  configurations,  cognition  errors  and  omissions  are 
measurable  if  the  task  assignment  provides  for  hard  copy  displays. 

All  of  the  cognition  variables  and  accession  frequency  can  only  be 
measured  for  the  last  three  configurations  all  of  which  provide  for  a 
computer  terminal  interface  with  the  decision  maker. 

5. 4. 4. 4  Shunting  Transfer  Experiments. 

This  is  the  class  of  experiments  that  might  be  termed  “trying 
to  define  the  undefinable,"  i.e.,  one  is  actually  trying  to  study  the 
lower  level  process/cognition  process  interface  with  an  inadequate 
tool.  In  fact,  it  is  this  very  property  that  makes  these  manual  con¬ 
figurations  inadequate  for  the  data  accession  measurements  that  one 
is  attmepting  to  study.  As  indicated  in  Tcble  5-14  Configurations  E, 

F,  and  E1  are,  therefore,  not  usable  fo|  this  purpose  in  that  a  com¬ 
puter  terminal  eliminates  shunting.  Otherwise,  the  same  considerations 
that  applied  to  Configurations  A  through  D  for  cognition  experiments 
also  apply  for  shunting  transfer. 

5.5  PROCEDURE 

As  pointed  out  in  the  introduction  to  this  section  (para  b.O), 
the  purpose  of  this  development  is  to  define  the  changes  and/or  additions 
that  may  be  required  to  a  specified  SOP  for  the  system  to  be  emulated 
in  order  to  insure  that  the  required  variables  are  controlled  or  mea¬ 
surable.  It  is  assumed  that  such  SOP  is  a  part  of  the  detailed  system 
description.  The  following  discussion,  therefore,  includes  only  a 
listing  of  the  minimum  contents  of  an  SOP  and  concentrates  on  the 
special  additional  task  assignments  that  must  be  imposed  in  order  to 
establish  control  and  measurabil i ty  of  the  needed  variables. 

5.5.1  Standard  Operating  Procedure  (SOP). 

The  SOP  for  the  system  being  emulated  must,  as  a  minimum, 
contain  the  following  element:  although  the  SOP  need  not  be  packaged 
in  this  implied  format: 

•  Poster  of  Personnel  and  Equipment.  This  includes  a 
listing  of  aTV  personnel  (usually  by  MOS  and  grade) 
comprising  a  normal  12-hour  shift  and  a  listing  of 
all  equipment.  In  the  manual  mcde  (Configurations  A 
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TABLE  5-14.  CONFIGURATION  fASK  ASSIGNMENTS  FOR  SHUNTING 
TRANSFER  EXPERIMENTS 
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through  D)  this  includes  such  seemingly  trivial 
equipment  such  as  pencils,  grease  pencils,  acetate, 
tracing  paper,  chairs  and  tables,  as  well  as  all 
communication  terminals,  duplicating  machines,  etc. 

•  Module  Layout.  This  is  a  plan  view  of  the  physical 
layout  of  the  staff  module,  drawn  to  scale,  and 
identifying  the  location  of  every  work  station  and 
the  normal  placement  of  personnel. 

•  List  of  Actions.  This  is  a  list  of  every  trans- 
action  type  that  will  be  processed  or  generated 
by  the  staff  module. 

•  List  of  Elementary  Operations.  This  is  a  listing 
of  every  manual  data  processing  operation  that  will 
be  carried  out  in  processing  all  action  types  listed, 
to  include  manual  interface  processes. 

•  Assignment  of  Elementary  Operations.  This  is  a 
designation  of  which  staff  members  will  normally 
perform  each  of  the  identified  elementary  operations 
and  which  members  are  authorized  to  perform  them. 

For  example,  the  SOP  may  authorize  everyone  to 
answer  the  telephone,  only  the  operations  sergeant 
ar.d  $-3  to  update  the  SITMAP,  and  only  the  3-3  to 
release  an  order  to  subordinate  commands. 

•  Sequence  of  Elementary  Operations.  This  is  an 
indication,  usually  in  flow  chart  form,  of  the 
sequerce  in  which  the  operations  are  normally 
perfonned  for  every  action  type  to  be  processed. 

•  Schedule  of  Periodic  Actions.  This  is  a  listing  of 
the  times  at  which  each  periodic  action  is  to  be 
initiated  and  submitted. 

It  will  be  noted  that  the  above  requirements  are  somewhat  more  detailed 
than  SOPs  prepared  by  most  tactical  units  in  the  field.  Nevertheless, 
such  a  detailed  SOP  exists  in  the  minds  of  knowledgeable  and  experienced 
operations  sergeants  and  must  be  made  explicit  and  adhered  to  if  the 
required  degree  of  control  is  to  be  established  over  the  process  vari¬ 
ables  in  manual  staffs.  For  *n  ADP-assisted  module,  such  an  SOP  becomes 
simpler  and  less  voluminous  as  more  and  more  elementary  operations  are 
performed  by  the  computer  and  the  SOP  becomes  more  nearly  a  set  of 
terminal  operating  instructions. 
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5.5.2  Modifying  the  SOP. 


Having  acquired  and  fleshed  out,  as  necessary,  the  SOP  for  the 
system  being  emulated,  the  following  series  of  steps  will  determine 
the  modifications  and  augmentations  needed  to  perform  the  desired 
experiment. 

5. 5. 2.1  Class  of  Experiment. 

Determine  into  which  of  the  four  experimental  classes  i:he 
desired  experiment  falls  (data  accession,  lower  level  process,  cogni¬ 
tion,  or  shunting  transfer  as  defined  in  para  5.4.3).  Table  5-10  will 
be  useful  for  this  purpose  since  it  identifies  the  potential  indepen¬ 
dent  and  dependent  variables  for  each  class. 

5. 5. 2. 2  Configuration. 

The  next  step  is  to  choose,  from  those  available,  the  con¬ 
figuration  which  most  nearly  meets  the  purposes  of  the  experiment. 

This  can  be  done  with  the  aid  of  Tables  5-11  through  5-14  selecting 
the  table  appropriate  for  the  class  of  experiment.  For  example,  if 
one  wanted  to  collect  performance  data  for  the  lower  level  processes 
in  an  ADP-assisted  mode,  one  must  select  Configuration  F.  If,  on 
the  other  hand,  one  wanted  to  collect  such  data  on  a  manual  system 
one  would  have  to  select  from  A  through  D  depending  on  which  lower 
level  processes  one  wanted  data  for.  In  general,  one  would  select 
chat  configuration  with  the  fewest  lower  level  processes  within  the 
staff  module  in  order  to  reduce  the  scope  of  the  control  problem  (as 
well  as  cost). 

5. 5. 2. 3  SOP  Modification. 

The  next  and  last  step  is  to  modify  the  SOP  to  facilitate 
control  or  measurement,  as  appropriate,  of  those  variables  for  which 
controls  must  be  imposed  on  tr^  players.  To  determine  this,  refer  to 
the  appropriate  table  (5-11  through  5-14)  for  the  class  of  experiment 
and  select  the  row  corresponding  to  the  configuration  selected. 
Appropriate  revision  must  now  be  made  to  the  SOP  to  control  every 
variable  which  has  an  entry  of  TA.  In  general,  this  applies  to  the 
process  variables  for  all  manual  processing  which  consists  or  two  or 
more  consecutive,  manual  processes.  This  includes  Configuration  F, 
and  ADP-assisted  case.  If  the  speed,  accuracy,  completeness,  and 
sequencing  of  such  processes  is  to  be  controlled,  their  values  must 
be  measured.  This  requires  recording  of  the  time  cf  transfer  (com¬ 
pletion)  and  time  of  initiation  of  every  manually  performed  lower 
level  process.  Means  which  interfere  minimally  with  the  normal  pro¬ 
cessing  should  be  selected.  For  example,  recording  clocks  mounted  at 
all  appropriate  work  stations  can  be  used  to  record  such  times  o:i  every 
written  data  exchange.  The  same  time  clock  can  also  record  an  identifer 
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for  the  operator  performing  that  process.  Finally,  the  SOP  murt  be 
modified  to  provide  for  limiting  data  exchanges  to  hard  copy  if  the 
error  rate  and  omission  rate  are  to  be  measured  and  controlled.  There 
is  one  other  class  of  SOP  changes  that  must  be  incorporated  if  error 
rates  and  omissions  are  to  oe  measured  for  the  cognitive  processes 
utilizing  one  of  the  manual  configurations.  This  involves  modifying 
the  SOP  for  all  visible  files  and  displays  accessed  by  the  decision 
maker  to  insure  that  a  permanent  copy  is  made  of  all  updates  to  those 
files.  Only  in  this  way  can  a  reference  standard  be  maintained  for 
measurement  of  errors  and  omissions  in  the  course  of  this  processing. 
If  the  appropriate  fable  also  has  an  entry  of  P.  Std.  for  a  particular 
variable  (limited  to  the  lower  level  process  variables)  one  must  also 
select  personnel  who  have  passed  some  minimum  standard  of  performance 
of  these  lower  level  processes  in  order  to  have  some  control  over  the 
delays  and  errors  introduced  into  the  section  data  base  actually 
accesssed  by  the  decision  maker.  These  performance  levels  must  be 
determined  from  the  degree  of  data  base  degradation  that  can  be  toler¬ 
ated  for  a  particular  experiment. 
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